OWASP Top-10 2013

Dave Wichers

OWASP Top 10 Project Lead

OWASP Board Member

Cofounder, Aspect Security & Contrast Security

Dave Wichers

• OWASP– OWASP Top 10 Project Lead– OWASP Board Member– Conferences Chair for 2005

thru 2008

• Cofounder Aspect Security– Application Security Consulting

• Cofounder Contrast Security– IAST Vulnerability Detection

Product

Hosted by OWASP & the NYC Chapter

About the OWASP Top 10

3

• Not a standard…

OWASP Top 10 is an Awareness Document

• Was probably 3rd or 4th OWASP project, after • Developers Guide• WebGoat• Maybe WebScarab ??

First developed in 2003

• 2003, 2004, 2007, 2010, 2013

Released

OWASP Top Ten (2013 Edition)

4

A1: Injection

A2: Broken Authentication

and Session Management

A3: Cross-Site Scripting (XSS)

A4: Insecure Direct Object References

A5: Security Misconfiguration

A6: Sensitive Data Exposure

A7: Missing Function Level Access Control

A8: Cross Site Request Forgery

(CSRF)

A9: Using Known Vulnerable

Components

A10: Unvalidated Redirects and

Forwards

What Didn’t Change

5

• Title is: “The Top 10 Most Critical Web Application Security Risks”

It’s About Risks, Not Just Vulnerabilities

• Based on the OWASP Risk Rating Methodology, used to prioritize Top 10

OWASP Top 10 Risk Rating Methodology

OWASP Top 10 Risk Rating Methodology

6

ThreatAgent

AttackVector Weakness Prevalence Weakness Detectability Technical Impact Business Impact

?Easy Widespread Easy Severe

?Average Common Average Moderate

Difficult Uncommon Difficult Minor

1 2 2 1

1.66 * 1

1.66 weighted risk rating

Injection Example

123

What’s Changed?

7

• Reordered: 7• Added: 1• Merged: 2 merged into 1• Broadened: 1

Risks Added, Risks Merged, Risks Reordered

• Same as 2010, but• Used more sources of vulnerability data• All vulnerability data made public by each provider

Development Methodology For 2013

• More transparency• Requested vulnerability data format• Earlier community involvement

Development Methodology for Next Version?

Mapping from 2010 to 2013 Top 10

OWASP Top 10 – 2010 (old) OWASP Top 10 – 2013 (New)2010-A1 – Injection 2013-A1 – Injection

2010-A2 – Cross Site Scripting (XSS) 2013-A2 – Broken Authentication and Session Management

2010-A3 – Broken Authentication and Session Management 2013-A3 – Cross Site Scripting (XSS)

2010-A4 – Insecure Direct Object References 2013-A4 – Insecure Direct Object References

2010-A5 – Cross Site Request Forgery (CSRF) 2013-A5 – Security Misconfiguration

2010-A6 – Security Misconfiguration 2013-A6 – Sensitive Data Exposure

2010-A7 – Insecure Cryptographic Storage 2013-A7 – Missing Function Level Access Control

2010-A8 – Failure to Restrict URL Access 2013-A8 – Cross-Site Request Forgery (CSRF)

2010-A9 – Insufficient Transport Layer Protection 2013-A9 – Using Known Vulnerable Components (NEW)

2010-A10 – Unvalidated Redirects and Forwards (NEW) 2013-A10 – Unvalidated Redirects and Forwards

3 Primary Changes: Merged: 2010-A7 and 2010-A9 -> 2013-A6

Added New 2013-A9: Using Known Vulnerable Components 2010-A8 broadened to 2013-A7

OWASP Top Ten 2010-A6 Security Misconfiguration

9

How Do I Prevent This?The primary recommendations are to establish all of the following:…2. A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment. This needs to include all code libraries as well, which are frequently overlooked.”

80% Libraries But library use is growing at a staggering rate

The amount of custom codein an application hasn’t changedvery much in the past 10 years.

10

Transformation

80% Libraries But library use is growing at a

staggering rate

20% Custom Code

GWT

Apache Xerce

s

Sprin

g MVC

Struts

1.x

Apache CXF

Struts2

Apache Axis

Sprin

g Secu

rity

Tapestry

Wick

etLift

Apache Sa

ntuario

BouncyCastl

eTile

s

Hibernate

Apache Sh

iro

Java Se

rver F

aces

AntiSamy

100

1,000

10,000

100,000

1,000,000

10,000,000

100,000,000

Everyone Uses Vulnerable Libraries

29 MILLION vulnerable

downloads in 2011

Libraries 31Library Versions

1,261

Organizations 61,807Downloads 113,939,358

Vul-nerable Down-

load

26%

Safe Down-load

74%

https://www.aspectsecurity.com/news/press/the-unfortunate-reality-of-insecure-libraries

2013-A9 – Using Known Vulnerable Components

13

• 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

Vulnerable Components Are Common

• 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

Widespread

• 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

Typical Impact

What Can You Do to Avoid This?

14

• Automation checks periodically (e.g., nightly build) to see if your libraries are out of date

• Even better, automation also tells you about known vulnerabilities

Ideal

• By hand, periodically check to see if your libraries are out of date and upgrade those that are

• If any are out of date, but you really don’t want to upgrade, check to see if there are any known security issues with these out of data libraries• If so, upgrade those

Minimum

• By hand, periodically check to see if any of your libraries have any known vulnerabilities at this time• Check CVE, other vuln repositories• If any do, update at least these

Could also

Automation Example for Java-Maven Versions Plugin

15

Output from the Maven Versions Plugin – Automated Analysis of Libraries’ Status against Central repository

Most out of Date!

Details Developer Needs

This can automatically be run EVERY TIME software is built!!

OWASP Dependency Check

Run DependencyCheck during every build(and do a build once a month even if nothing changed)

The Merged 2013-A6 – Sensitive Data Exposure

17

• 2010-A7 – Insecure Cryptographic Storage• 2010-A9 – Insufficient Transport Layer Protection• To make room for New 2013-A9: Using Known Vulnerable Components

Two Related Topics Merged

• 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

Storing and Transmitting Sensitive Data Insecurely

Expanded A7-Missing Function Level Access Control

18

• URLs are one way to access functions• But not the only way …

Was: 2010-A8 – Failure to Restrict URL Access

• URL to function directly• URL plus parameter value(s) which indicate which function is being accessed

• e.g., site/somedir/somepage?action=transferfunds

Expand to Cover all Ways a Function Can Be Accessed

• Application simply doesn’t check to see if function invocation is authorized• Application does check for authorization, but check is flawed. (This would

be broken function level access control, but missing is far more common.)

Typical Flaws

OWASP Top 10 2013 Development Methodology

19

• Ask previous contributors, solicit new contributors well known to Top 10 team, include unsolicited volunteers• 3 New Data Contributors Included: TrustWave, Veracode, Minded

Security• New: Each provider asked to make their data public. All Did.

Gather Vulnerability Stats

• Draft Released to OWASP Community Feb 15, 2013• Public Comment Period Open for 90+ days (thru May 30, 2013)

Analyze Stats, Produce Initial Draft, Release for Public Comment

• All Constructive Comments Considered• Full documentation of Constructive Comments and how they were

addressed documented• https://www.owasp.org/images/3/3d/OWASP_Top_10_-_2013_Final_

Release_-_Change_Log.docx

• Released on June 12, 2013

Final Release Produced

Top 10 Future Development Methodology Ideas

20

• Issue Open Call For Vulnerability Stats Providers• Provide Desired Stats Format (for consistency) and Require Public

Reporting• Consider all Stats Provided by Requested Deadline• Don’t Ignore Future Looking Threats

• Like we did with CSRF in 2007, and Vulnerable Components in 2013

Gather More Stats More Openly

• We only have Vulnerability Prevalence Stats• What about Stats for Exploitability, Detectability, Impact?• We tried to consider some Exploitability stats in 2013, but couldn’t find

effective public stats

Consider Other Stats if They Make Sense

• Solicit Additional Volunteers

Expand Authoring Team

• Video Presentation of Each Item in OWASP Top 10 – 2010 (which is very similar)– Dave Wichers at OWASP AppSec DC (2009)– http://www.vimeo.com/9006276

• OWASP Top 10 – 2013 Presentation which goes through each item one by one– https://www.owasp.org/index.php/Top10

• Translations of OWASP Top 10 - 2013– French, Portuguese, Spanish, Chinese, Korean, Japanese, Arabic Translations

complete– Many others underway– https://www.owasp.org/index.php/Top10#tab=Translation_Efforts

OWASP Top 10 Resources

21

Thank youOWASP Top-10 Project