What is OWASP, and Why Should I care?

1. The Open Web Application
Security Project
Brett Gravois
Web Application Pentester
brett.gravois@owasp.org
Twitter: @security_panda
June 14th 2017

2. Whois:
• Brett Gravois
• OWASP IE FounderLeader
• Web Application Pentester
• Owner of an Epic Beard

4. What the heck is OWASP?
• OWASP is a worldwide free and open community focused
on improving the security of application software.
• Our mission is to make application security visible so that
people and organizations can make informed decisions
about application security risks.
• Everyone is free to participate in OWASP and all of our
materials are available under a free and open software
license.
• The OWASP Foundation is a 501c3 not-for-profit charitable
organization that ensures the ongoing availability and
support for our work.

5. OWASP Supporters

6. Roughly Around 276+ Active Chapters around
the world in 108n countries.

7. Over 93 Active Projects
Including:
• OWASP Top 10
• Embedded Linux
• OWASP Zed Attack Proxy
• OWASP Security Shepherd
• OWASP Broken Web App
• Juice Shop

8. Why should I care about OWASP?
The importance of application security (AppSec)
is widely understood, with 97 percent of
respondents to the SANS Institute’s 2016 State
of Application Security report revealing they
have an AppSec program in place.

9. Why should I care about OWASP?
However, only 26 percent of respondents
described their AppSec program as mature or
very mature. Clearly work must still be done,
and that’s where something like the Open Web
Application Security Project can prove very
useful.

10. OWASP a source of impartial advice
The competitive technology and services market has
plenty to say, but much of it is designed to steer you
toward a particular tool or service provider.
The OWASP was created to combat that issue, offering
genuinely impartial advice on best practices and fostering
the creation of open standards.
Recommendations for commercial products and services
are considered inappropriate. The OWASP aims to be a
pool of knowledge that you can genuinely trust, free of
ulterior motives.

11. Enter the OWASP Top 10
The list was last published in 2013, and it is in the process of being updated, but it’s
still a valid and valuable run-down of some of the major risks. Here’s the list:
1. Injection
2. Broken Authentication and Session Management
3. Cross-Site Scripting (XSS)
4. Insecure Direct Object References
5. Security Misconfiguration
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross-Site Request Forgery (CSRF)
9. Using Components with Known Vulnerabilities
10. Unvalidated Redirects and Forwards

12. OWASP Top 10 (Cont.)
Every entry is broken down in great detail, so
developers can find out whether they’re
vulnerable and learn how to prevent an attack.
There are also example attack scenarios and
further references to help identify
vulnerabilities, eradicate them and test to
ensure they’re properly dealt with.

13. OWASP Top 10 (Cont.)
As many as 25 percent of web apps today are
vulnerable to eight of the entries on the OWASP
Top 10, according to Contrast Security research, and
80 percent had at least one vulnerability. The
organization found that sensitive data exposure
topped the list, affecting 69 percent of web apps
tested. CSRF was second, affecting 55 percent of
apps, and broken authentication and session
management was third, affecting 41 percent of
apps.

14. SANS Top 3 AppSec challenges
• 33 percent pointed to silos between security,
development and business units, making it
hard to establish ultimate responsibility and
preventing effective collaboration
• 37 percent lament the lack of funding and
management buy-in
• 38 percent reported a lack of application
security skills, tools and methods

15. OWASP Top 10
• OWASP Top 10 is an Awareness Document!
Not a standard…
• First Developed in 2003
Was probably 3rd or 4th OWASP project, after
– Developers Guide
– WebGoat
– Maybe WebScarab ??
• Released
2003, 2004, 2007, 2010, 2013, 2017 (RC1)

16. OWASP Top 10
• It’s About Risks, Not Just Vulnerabilities
– Title is: “The Top 10 Most Critical Web Application Security
Risks”
• OWASP Top 10 Risk Rating Methodology
– Based on the OWASP Risk Rating Methodology, used to
prioritize Top 10

17. 2013-A1 – Injection
• Injection means…
– Tricking an application into including unintended commands in the
data sent to an interpreter
• Interpreters…
– Take strings and interpret them as commands
– SQL, OS Shell, LDAP, XPath, Hibernate, etc…
• SQL injection is still quite common
– Many applications still susceptible (really don’t know why)
– Even though it’s usually very simple to avoid
• Typical Impact
– Usually severe. Entire database can usually be read or modified
– May also allow full database schema, or account access, or even OS
level access

18. 2013-A2 – Broken Authentication and
Session Management
• HTTP is a “stateless” protocol
– Means credentials have to go with every request
– Should use SSL for everything requiring authentication
• Session management flaws
– SESSION ID used to track state since HTTP doesn’t
• and it is just as good as credentials to an attacker
– SESSION ID is typically exposed on the network, in browser, in
logs, …
• Beware the side-doors
– Change my password, remember my password, forgot my
password, secret question, logout, email address, etc…
• Typical Impact
– User accounts compromised or user sessions hijacked

19. 2013-A3 – Cross-Site Scripting (XSS)
• Occurs any time…
– Raw data from attacker is sent to an innocent user’s browser
• Raw data…
– Stored in database
– Reflected from web input (form field, hidden field, URL, etc…)
– Sent directly into rich JavaScript client
• Virtually every web application has this problem
– Try this in your browser – javascript:alert(document.cookie)
• Typical Impact
– Steal user’s session, steal sensitive data, rewrite web page, redirect
user to phishing or malware site
– Most Severe: Install XSS proxy which allows attacker to observe and
direct all user’s behavior on vulnerable site and force user to other
sites

20. 2013-A4 – Insecure Direct Object
References
• How do you protect access to your data?
– This is part of enforcing proper “Authorization”, along with
A7 – Failure to Restrict URL Access
• A common mistake …
– Only listing the ‘authorized’ objects for the current user, or
– Hiding the object references in hidden fields
– … and then not enforcing these restrictions on the server side
– This is called presentation layer access control, and doesn’t
work
– Attacker simply tampers with parameter value
• Typical Impact
– Users are able to access unauthorized files or data

21. 2013-A5 – Security Misconfiguration
• Web applications rely on a secure foundation
– Everywhere from the OS up through the App Server
• Is your source code a secret?
– Think of all the places your source code goes
– Security should not require secret source code
• CM must extend to all parts of the application
– All credentials should change in production
• Typical Impact
– Install backdoor through missing OS or server patch
– Unauthorized access to default accounts, application
functionality or data, or unused but accessible functionality
due to poor server configuration

22. 2013-A6 – Sensitive Data Exposure
• Storing and transmitting sensitive data insecurely
– Failure to identify all sensitive data
– Failure to identify all the places that this sensitive data gets stored
• Databases, files, directories, log files, backups, etc.
– Failure to identify all the places that this sensitive data is sent
• On the web, to backend databases, to business partners, internal communications
– Failure to properly protect this data in every location
• Typical Impact
– Attackers access or modify confidential or private information
• e.g, credit cards, health care records, financial data (yours or your customers)
– Attackers extract secrets to use in additional attacks
– Company embarrassment, customer dissatisfaction, and loss of trust
– Expense of cleaning up the incident, such as forensics, sending apology letters,
reissuing thousands of credit cards, providing identity theft insurance
– Business gets sued and/or fined

23. 2013-A7 – Missing Function Level
Access Control
• How do you protect access to URLs (pages)?
• Or functions referenced by a URL plus parameters ?
– This is part of enforcing proper “authorization”, along with
A4 – Insecure Direct Object References
• A common mistake …
– Displaying only authorized links and menu choices
– This is called presentation layer access control, and doesn’t work
– Attacker simply forges direct access to ‘unauthorized’ pages
• Typical Impact
– Attackers invoke functions and services they’re not authorized for
– Access other user’s accounts and data
– Perform privileged actions

24. 2013-A8 – Cross Site Request Forgery
(CSRF)
• Cross Site Request Forgery
– An attack where the victim’s browser is tricked into issuing a command to a
vulnerable web application
– Vulnerability is caused by browsers automatically including user
authentication data (session ID, IP address, Windows domain credentials, …)
with each request
• Imagine…
– What if a hacker could steer your mouse and get you to click on links in your
online banking application?
– What could they make you do?
• Typical Impact
– Initiate transactions (transfer funds, logout user, close account)
– Access sensitive data
– Change account details

25. 2013-A9 – Using Known Vulnerable
Components
• Vulnerable Components Are Common
– Some vulnerable components (e.g., framework libraries) can be identified
and exploited with automated tools
– This expands the threat agent pool beyond targeted attackers to include
chaotic actors
• Widespread
– Virtually every application has these issues because most development
teams don’t focus on ensuring their components/libraries are up to date
– In many cases, the developers don’t even know all the components they are
using, never mind their versions. Component dependencies make things
even worse
• Typical Impact
– Full range of weaknesses is possible, including injection, broken access
control, XSS ...
– The impact could range from minimal to complete host takeover and data
compromise

26. 2013-A10 – Unvalidated Redirects and
Forwards
• Web application redirects are very common
– And frequently include user supplied parameters in the destination URL
– If they aren’t validated, attacker can send victim to a site of their choice
• Forwards (aka Transfer in .NET) are common too
– They internally send the request to a new page in the same application
– Sometimes parameters define the target page
– If not validated, attacker may be able to use unvalidated forward to bypass
authentication or authorization checks
• Typical Impact
– Redirect victim to phishing or malware site
– Attacker’s request is forwarded past security checks, allowing unauthorized
function or data access

27. OWASP Top 10 2017 Changes

28. 2017-A4: Broken Access Control
2013-A4: Insecure Direct Object References will be
merged with 2013-A7: Missing Function Level
Access Control back into 2017-A4: Broken Access
Control.
In 2007, OWASP split Broken Access Control into
these two categories to bring more attention to
each half of the access control problem (data and
functionality). Felt this was no longer necessary
they were merged back together.

29. 2017-A7: Insufficient Attack Protection
For years, considered adding insufficient
defenses against automated attacks. Based on
the data call, we see that the majority of
applications and APIs lack basic capabilities to
detect, prevent, and respond to both manual
and automated attacks. Application and API
owners also need to be able to deploy patches
quickly to protect against attacks.

30. 2017-A10: Underprotected APIs
Modern applications and APIs often involve rich
client applications, such as JavaScript in the
browser and mobile apps, that connect to an API
of some kind (SOAP/XML, REST/JSON, RPC, GWT,
etc.). These APIs are often unprotected and
contain numerous vulnerabilities. We include it
here to help organizations focus on this major
emerging exposure.

31. 2013-A10: Unvalidated Redirects and
Forwards
In 2010, this category was added to raise
awareness of this problem. However, the data
shows that this issue isn’t as prevalent as
expected. So after being in the last two releases
of the Top 10, this time it didn’t make the cut.