owasp top 10 2013 ebook

7/27/2019 Owasp Top 10 2013 eBook

1/22

7/27/2019 Owasp Top 10 2013 eBook

2/22

O About OWASP

opyright and License

Copyright 2003 2013 The OWASP Foundation

This document is released under the Creative Commons Attribution ShareAlike 3.0 license. For any reu

or distribution, you must make it clear to others the license terms of this work.

oreword

ecure software is undermining our financial, healthcare,

ense, energy, and other critical infrastructure. As our

tal infrastructure gets increasingly complex and

erconnected, the difficulty of achieving application

urity increases exponentially. We can no longer afford to

erate relatively simple security problems like those

sented in this OWASP Top 10.

e goal of the Top 10 project is to raise awareness about

plication security by identifying some of the most critical

ks facing organizations. The Top 10 project is referenced

many standards, books, tools, and organizations, including

TRE, PCI DSS, DISA, FTC, and many more. This release of

OWASP Top 10 marks this projects tenth anniversary of

sing awareness of the importance of application security

ks. The OWASP Top 10 was first released in 2003, with

nor updates in 2004 and 2007. The 2010 version was

amped to prioritize by risk, not just prevalence. This 2013

tion follows the same approach.

encourage you to use the Top 10 to get your organization

rted with application security. Developers can learn from

mistakes of other organizations. Executives should startnking about how to manage the risk that software

plications create in their enterprise.

he long term, we encourage you to create an application

urity program that is compatible with your culture and

hnology. These programs come in all shapes and sizes,

d you should avoid attempting to do everything prescribed

some process model. Instead, leverage your

anizations existing strengths to do and measure what

rks for you.

hope that the OWASP Top 10 is useful to your application

urity efforts. Please dont hesitate to contact OWASP with

ur questions, comments, and ideas, either publicly to

[email protected] or privately to

[email protected].

About OWASP

The Open Web Application Security Project (OWASP) is an

open community dedicated to enabling organizations to

develop, purchase, and maintain applications that can be

trusted. At OWASP youll find free and open

Application security tools and standards

Complete books on application security testing, secure

code development, and secure code review

Standard security controls and libraries

Local chapters worldwide

Cutting edge research

Extensive conferences worldwide

Mailing lists

Learn more at: https://www.owasp.org

All of the OWASP tools, documents, forums, and chapters ar

free and open to anyone interested in improving application

security. We advocate approaching application security as a

people, process, and technology problem, because the most

effective approaches to application security require

improvements in all of these areas.

OWASP is a new kind of organization. Our freedom from

commercial pressures allows us to provide unbiased, practica

cost-effective information about application security. OWAS

is not affiliated with any technology company, although we

support the informed use of commercial security technology

Similar to many open source software projects, OWASP

produces many types of materials in a collaborative, open w

The OWASP Foundation is the non-profit entity that ensures

the projects long-term success. Almost everyone associated

with OWASP is a volunteer, including the OWASP Board,Global Committees, Chapter Leaders, Project Leaders, and

project members. We support innovative security research

with grants and infrastructure.

Come join us!
https://www.owasp.org/index.php/Industry:Citationsmailto:[email protected]://www.owasp.org/index.php/Category:OWASP_Chapterhttps://www.owasp.org/index.php/Category:OWASP_AppSec_Conferencehttps://lists.owasp.org/mailman/listinfohttps://www.owasp.org/https://www.owasp.org/https://lists.owasp.org/mailman/listinfohttps://www.owasp.org/index.php/Category:OWASP_AppSec_Conferencehttps://www.owasp.org/index.php/Category:OWASP_Chapterhttps://www.owasp.org/index.php/Category:OWASP_Chapterhttps://www.owasp.org/index.php/Category:OWASP_Chaptermailto:[email protected]:[email protected]:[email protected]:[email protected]://www.owasp.org/index.php/Industry:Citationshttp://creativecommons.org/licenses/by-sa/3.0/

7/27/2019 Owasp Top 10 2013 eBook

3/22

Welcome

lcome to the OWASP Top 10 2013! This update broadens one of the categories from the 2010 version to be more inclusive o

mmon, important vulnerabilities, and reorders some of the others based on changing prevalence data. It also brings

mponent security into the spotlight by creating a specific category for this risk, pulling it out of the obscurity of the fine print

2010 risk A6: Security Misconfiguration.

e OWASP Top 10 for 2013 is based on 8 datasets from 7 firms that specialize in application security, including 4 consulting

mpanies and 3 tool/SaaS vendors (1 static, 1 dynamic, and 1 with both). This data spans over 500,000 vulnerabilities across

ndreds of organizations and thousands of applications. The Top 10 items are selected and prioritized according to this

valence data, in combination with consensus estimates of exploitability, detectability, and impact estimates.

e primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the

nsequences of the most important web application security weaknesses. The Top 10 provides basic techniques to protect

inst these high risk problem areas and also provides guidance on where to go from here.

Warnings

nt stop at 10. There are hundreds of issues that could

ect the overall security of a web application as discussed in

OWASP Developers Guide and the OWASP Cheat Sheet

ies. These are essential reading for anyone developing

b applications. Guidance on how to effectively find

nerabilities in web applications is provided in the OWASP

ting Guide and the OWASP Code Review Guide.

nstant change. This Top 10 will continue to change. Even

hout changing a single line of your applications code, you

y become vulnerable as new flaws are discovered and

ack methods are refined. Please review the advice at the

d of the Top 10 in Whats Next For Developers, Verifiers,

d Organizations for more information.

nk positive. When youre ready to stop chasing

nerabilities and focus on establishing strong application

urity controls, OWASP has produced the Applicationurity Verification Standard (ASVS) as a guide to

anizations and application reviewers on what to verify.

e tools wisely. Security vulnerabilities can be quite

mplex and buried in mountains of code. In many cases, the

st cost-effective approach for finding and eliminating

se weaknesses is human experts armed with good tools.

sh left. Focus on making security an integral part of your

ture throughout your development organization. Find out

re in the Open Software Assurance Maturity ModelMM) and the Rugged Handbook.

Attribution

Thanks to Aspect Security for initiating, leading, and updatin

the OWASP Top 10 since its inception in 2003, and to its

primary authors: Jeff Williams and Dave Wichers.

Wed like to thank those organizations that contributed thei

vulnerability prevalence data to support the 2013 update:

Aspect SecurityStatistics

HPStatistics from both Fortify and WebInspect

Minded SecurityStatistics

SofttekStatistics

Trustwave, SpiderLabsStatistics (See page 50)

VeracodeStatistics

WhiteHat Security Inc.Statistics

We would like to thank everyone who contributed to previouversions of the Top 10. Without these contributions, it

wouldnt be what it is today. Wed also like to thank those w

contributed significant constructive comments and time

reviewing this update to the Top 10:

Adam Baso (Wikimedia Foundation)

Mike Boberski (Booz Allen Hamilton)

Torsten Gigler

Neil Smithline (MorphoTrust USA) For producing the

wiki version of the Top 10, and also providing feedbac

And finally, wed like to thank in advance all the translators othere that will translate this release of the Top 10 into

numerous different languages, helping to make the OWASP

Top 10 more accessible to the entire planet.

I Introduction
https://www.owasp.org/index.php/OWASP_Guide_Projecthttps://www.owasp.org/index.php/Cheat_Sheetshttps://www.owasp.org/index.php/Cheat_Sheetshttps://www.owasp.org/index.php/Category:OWASP_Testing_Projecthttps://www.owasp.org/index.php/Category:OWASP_Testing_Projecthttps://www.owasp.org/index.php/Category:OWASP_Code_Review_Projecthttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Modelhttps://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Modelhttp://ruggedsoftware.org/https://www.aspectsecurity.com/https://www.aspectsecurity.com/https://www.aspectsecurity.com/uploads/downloads/2013/06/Aspect-2013-Global-AppSec-Risk-Report.pdfhttp://www.hpenterprisesecurity.com/http://www.hpenterprisesecurity.com/collateral/whitepaper/HP2012CyberRiskReport_0313.pdfhttp://www.mindedsecurity.com/http://blog.mindedsecurity.com/2013/02/real-life-vulnerabilities-statistics.htmlhttp://www.softtek.com/https://www.softtek.com/webdocs/special_pdfs/WP-State-of-the-art-2013.pdfhttps://www.trustwave.com/spiderlabs/http://www2.trustwave.com/rs/trustwave/images/2013-Global-Security-Report.pdfhttp://www.veracode.com/http://info.veracode.com/rs/veracode/images/VERACODE-SOSS-V4.PDFhttps://www.whitehatsec.com/http://owasptop10.googlecode.com/files/WPstats_winter11_11th.pdfhttp://owasptop10.googlecode.com/files/WPstats_winter11_11th.pdfhttps://www.whitehatsec.com/http://info.veracode.com/rs/veracode/images/VERACODE-SOSS-V4.PDFhttp://www.veracode.com/http://www2.trustwave.com/rs/trustwave/images/2013-Global-Security-Report.pdfhttps://www.trustwave.com/spiderlabs/https://www.softtek.com/webdocs/special_pdfs/WP-State-of-the-art-2013.pdfhttp://www.softtek.com/http://blog.mindedsecurity.com/2013/02/real-life-vulnerabilities-statistics.htmlhttp://www.mindedsecurity.com/http://www.hpenterprisesecurity.com/collateral/whitepaper/HP2012CyberRiskReport_0313.pdfhttp://www.hpenterprisesecurity.com/https://www.aspectsecurity.com/uploads/downloads/2013/06/Aspect-2013-Global-AppSec-Risk-Report.pdfhttps://www.aspectsecurity.com/https://www.aspectsecurity.com/http://ruggedsoftware.org/https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Modelhttps://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Modelhttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/Category:OWASP_Code_Review_Projecthttps://www.owasp.org/index.php/Category:OWASP_Testing_Projecthttps://www.owasp.org/index.php/Category:OWASP_Testing_Projecthttps://www.owasp.org/index.php/Cheat_Sheetshttps://www.owasp.org/index.php/Cheat_Sheetshttps://www.owasp.org/index.php/OWASP_Guide_Project

7/27/2019 Owasp Top 10 2013 eBook

4/22

What Changed From 2010 to 2013?

e threat landscape for applications security constantly changes. Key factors in this evolution are advances made by attackers

release of new technologies with new weaknesses as well as more built in defenses, and the deployment of increasingly

mplex systems. To keep pace, we periodically update the OWASP Top 10. In this 2013 release, we made the following change

Broken Authentication and Session Management moved up in prevalence based on our data set. We believe this is probab

because this area is being looked at harder, not because these issues are actually more prevalent. This caused Risks A2 and

A3 to switch places.

Cross-Site Request Forgery (CSRF) moved down in prevalence based on our data set from 2010-A5 to 2013-A8. We believe

this is because CSRF has been in the OWASP Top 10 for 6 years, and organizations and framework developers have focused

on it enough to significantly reduce the number of CSRF vulnerabilities in real world applications.

We broadened Failure to Restrict URL Access from the 2010 OWASP Top 10 to be more inclusive:

+ 2010-A8: Failure to Restrict URL Access is now 2013-A7: Missing Function Level Access Control to cover all of functio

level access control. There are many ways to specify which function is being accessed, not just the URL.

We merged and broadened 2010-A7 & 2010-A9 to CREATE: 2013-A6: Sensitive Data Exposure:

This new category was created by merging 2010-A7 Insecure Cryptographic Storage & 2010-A9 - Insufficient Transpo

Layer Protection, plus adding browser side sensitive data risks as well. This new category covers sensitive data

protection (other than access control which is covered by 2013-A4 and 2013-A7) from the moment sensitive data is

provided by the user, sent to and stored within the application, and then sent back to the browser again.

We added: 2013-A9: Using Known Vulnerable Components:

+ This issue was mentioned as part of 2010-A6 Security Misconfiguration, but now has a category of its own as the

growth and depth of component based development has significantly increased the risk of using known vulnerable

components.

OWASP Top 10 2010 (Previous) OWASP Top 10 2013 (New)

Injection A1 Injection

Broken Authentication and Session Management A2 Broken Authentication and Session Management

Cross-Site Scripting (XSS) A3 Cross-Site Scripting (XSS)

Insecure Direct Object References A4 Insecure Direct Object References

Security Misconfiguration A5 Security Misconfiguration

Insecure Cryptographic Storage Merged with A9 A6 Sensitive Data Exposure Failure to Restrict URL Access Broadened into A7 Missing Function Level Access Control Cross-Site Request Forgery (CSRF) A8 Cross-Site Request Forgery (CSRF)

uried in A6: Security Misconfiguration> A9 Using Known Vulnerable Components

0 Unvalidated Redirects and Forwards A10 Unvalidated Redirects and Forwards

Insufficient Transport Layer Protection Merged with 2010-A7 into new 2013-A6

Release NotesRN

7/27/2019 Owasp Top 10 2013 eBook

5/22

Weakness

Attack

ThreatAgents

ImpactWeakness

Attack

AttackVectors

SecurityWeaknesses

TechnicalImpacts

BusinessImpacts

Attack

Impact

Impact

Asset

Function

Asset

Weakness

Control

Control

ControlWeakness

SecurityControls

Application Security RisksRisk

References

OWASP

OWASP Risk Rating Methodology

Article on Threat/Risk Modeling

External

FAIR Information Risk Framework

Microsoft Threat Modeling (STRIDEand DREAD)

Whats My Risk?

e OWASP Top 10 focuses on identifying the most serious risks for a broad arrayorganizations. For each of these risks, we provide generic information aboutlihood and technical impact using the following simple ratings scheme, which ised on the OWASP Risk Rating Methodology.

y you know the specifics of your environment and your business. For any givenplication, there may not be a threat agent that can perform the relevant attack,he technical impact may not make any difference to your business. Therefore,

u should evaluate each risk for yourself, focusing on the threat agents, securityntrols, and business impacts in your enterprise. We list Threat Agents asplication Specific, and Business Impacts as Application / Business Specific toicate these are clearly dependent on the details about your application in yourerprise.

e names of the risks in the Top 10 stem from the type of attack, the type ofakness, or the type of impact they cause. We chose names that accuratelyect the risks and, where possible, align with common terminology most likely to

se awareness.

What Are Application Security Risks?

ackers can potentially use many different paths through your application to do harm to your business or organization. Each ose paths represents a risk that may, or may not, be serious enough to warrant attention.

metimes, these paths are trivial to find and exploit and sometimes they are extremely difficult. Similarly, the harm that issed may be of no consequence, or it may put you out of business. To determine the risk to your organization, you canluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with an estimathe technical and business impact to your organization. Together, these factors determine the overall risk.

Threat

Agents

Attack

Vectors

Weakness

Prevalence

Weakness

Detectability

Technical

Impacts

Business

Impacts

AppSpecific

Easy Widespread Easy Severe

App /Business

Specific

Average Common Average Moderate

Difficult Uncommon Difficult Minor
http://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/OWASP_Risk_Rating_Methodologyhttps://www.owasp.org/index.php/Threat_Risk_Modelinghttp://www.owasp.org/index.php/Command_Injectionhttp://fairwiki.riskmanagementinsight.com/http://msdn.microsoft.com/en-us/library/aa302419.aspxhttp://msdn.microsoft.com/en-us/library/aa302419.aspxhttp://msdn.microsoft.com/en-us/library/aa302419.aspxhttps://www.owasp.org/index.php/Top_10https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodologyhttps://www.owasp.org/index.php/OWASP_Risk_Rating_Methodologyhttps://www.owasp.org/index.php/Top_10http://msdn.microsoft.com/en-us/library/aa302419.aspxhttp://msdn.microsoft.com/en-us/library/aa302419.aspxhttp://fairwiki.riskmanagementinsight.com/http://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/Threat_Risk_Modelinghttps://www.owasp.org/index.php/OWASP_Risk_Rating_Methodologyhttp://www.owasp.org/index.php/Command_Injection

7/27/2019 Owasp Top 10 2013 eBook

6/22

Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to aninterpreter as part of a command or query. The attackers hostile data can trick the interpreterinto executing unintended commands or accessing data without proper authorization.

A1 Injection

Application functions related to authentication and session management are often notimplemented correctly, allowing attackers to compromise passwords, keys, or session tokens, orto exploit other implementation flaws to assume other users identities.

A2 BrokenAuthentication and

SessionManagement

XSS flaws occur whenever an application takes untrusted data and sends it to a web browserwithout proper validation or escaping. XSS allows attackers to execute scripts in the victimsbrowser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

A3 Cross-SiteScripting (XSS)

A direct object reference occurs when a developer exposes a reference to an internalimplementation object, such as a file, directory, or database key. Without an access control checor other protection, attackers can manipulate these references to access unauthorized data.

A4 InsecureDirect Object

References

Good security requires having a secure configuration defined and deployed for the application,frameworks, application server, web server, database server, and platform. Secure settingsshould be defined, implemented, and maintained, as defaults are often insecure. Additionally,software should be kept up to date.

A5 SecurityMisconfiguration

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, andauthentication credentials. Attackers may steal or modify such weakly protected data to conduccredit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such aencryption at rest or in transit, as well as special precautions when exchanged with the browser

A6 Sensitive DataExposure

Most web applications verify function level access rights before making that functionality visiblein the UI. However, applications need to perform the same access control checks on the serverwhen each function is accessed. If requests are not verified, attackers will be able to forgerequests in order to access functionality without proper authorization.

A7 MissingFunction LevelAccess Control

A CSRF attack forces a logged-on victims browser to send a forged HTTP request, including thevictims session cookie and any other automatically included authentication information, to avulnerable web application. This allows the attacker to force the victims browser to generaterequests the vulnerable application thinks are legitimate requests from the victim.

A8 - Cross-SiteRequest Forgery

(CSRF)

Components, such as libraries, frameworks, and other software modules, almost always run withfull privileges. If a vulnerable component is exploited, such an attack can facilitate serious dataloss or server takeover. Applications using components with known vulnerabilities mayundermine application defenses and enable a range of possible attacks and impacts.

A9 - UsingComponents with

KnownVulnerabilities

Web applications frequently redirect and forward users to other pages and websites, and useuntrusted data to determine the destination pages. Without proper validation, attackers canredirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

A10 Unvalidated

Redirects andForwards

OWASP Top 10 ApplicationSecurity Risks 2013T10

7/27/2019 Owasp Top 10 2013 eBook

7/22

lication Specific ExploitabilityEASY

PrevalenceCOMMON

DetectabilityAVERAGE

ImpactSEVERE

Application /Business Specif

sider anyone can sendusted data tosystem,uding externals, internals, andinistrators.

Attacker sendssimple text-basedattacks that exploitthe syntax of thetargetedinterpreter. Almostany source of datacan be an injectionvector, includinginternal sources.

Injection flaws occur when an applicationsends untrusted data to an interpreter.Injection flaws are very prevalent,particularly in legacy code. They are oftenfound in SQL, LDAP, Xpath, or NoSQLqueries; OS commands; XML parsers,SMTP Headers, program arguments, etc.Injection flaws are easy to discover whenexamining code, but frequently hard todiscover via testing. Scanners and fuzzers

can help attackers find injection flaws.

Injection can resultin data loss orcorruption, lack ofaccountability, ordenial of access.Injection cansometimes lead tocomplete hosttakeover.

Consider thebusiness value ofthe affected dataand the platformrunning theinterpreter. All dcould be stolen,modified, ordeleted. Could yreputation be

harmed?

xample Attack Scenarios

nario #1: The application uses untrusted data in thenstruction of the following vulnerable SQL call:

ring query = "SELECT * FROM accounts WHEREustID='" + request.getParameter("id") + "'";

nario #2: Similarly, an applications blind trust inmeworks may result in queries that are still vulnerable,g., Hibernate Query Language (HQL)):

uery HQLQuery = session.createQuery(FROM accountsHERE custID=' + request.getParameter("id") + "'");

both cases, the attacker modifies the id parameter valueher browser to send: ' or '1'='1. For example:

p://example.com/app/accountView?id=' or '1'='1

s changes the meaning of both queries to return all theords from the accounts table. More dangerous attacks

uld modify data or even invoke stored procedures.

m I Vulnerable To Injection?e best way to find out if an application is vulnerable toection is to verify that all use of interpreters clearlyarates untrusted data from the command or query. For

L calls, this means using bind variables in all preparedtements and stored procedures, and avoiding dynamiceries.

ecking the code is a fast and accurate way to see if theplication uses interpreters safely. Code analysis tools can

p a security analyst find the use of interpreters and tracedata flow through the application. Penetration testers candate these issues by crafting exploits that confirm thenerability.

tomated dynamic scanning which exercises the applicationy provide insight into whether some exploitable injection

ws exist. Scanners cannot always reach interpreters andve difficulty detecting whether an attack was successful.or error handling makes injection flaws easier to discover.

References

OWASPOWASP SQL Injection Prevention Cheat Sheet

OWASP Query Parameterization Cheat Sheet

OWASP Command Injection Article

OWASP XML eXternal Entity (XXE) Reference Article

ASVS: Output Encoding/Escaping Requirements (V6)

OWASP Testing Guide: Chapter on SQL Injection Testing

External

CWE Entry 77 on Command Injection

CWE Entry 89 on SQL Injection

CWE Entry 564 on Hibernate Injection

How Do I Prevent Injection?Preventing injection requires keeping untrusted dataseparate from commands and queries.

1. The preferred option is to use a safe API which avoids tuse of the interpreter entirely or provides aparameterized interface. Be careful with APIs, such asstored procedures, that are parameterized, but can stilintroduce injection under the hood.

2. If a parameterized API is not available, you should

carefully escape special characters using the specificescape syntax for that interpreter. OWASPs ESAPIprovides many of these escaping routines.

3. Positive or white list input validation is alsorecommended, but is not a complete defense as manyapplications require special characters in their input. Ifspecial characters are required, only approaches 1. andabove will make their use safe. OWASPs ESAPI has anextensible library ofwhite list input validation routines.

A1 Injection

Security

Weakness

Attack

VectorsTechnical

ImpactsThreatAgents

Business

Impacts
http://www.owasp.org/index.php/Injection_Flawshttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheethttps://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheethttps://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/XXEhttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)http://www.owasp.org/index.php/Command_Injectionhttp://cwe.mitre.org/data/definitions/77.htmlhttp://cwe.mitre.org/data/definitions/89.htmlhttp://cwe.mitre.org/data/definitions/564.htmlhttps://www.owasp.org/index.php/ESAPIhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.htmlhttps://www.owasp.org/index.php/ESAPIhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.htmlhttps://www.owasp.org/index.php/ESAPIhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Validator.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Validator.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Validator.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Validator.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Validator.htmlhttps://www.owasp.org/index.php/ESAPIhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encoder.htmlhttps://www.owasp.org/index.php/ESAPIhttp://cwe.mitre.org/data/definitions/564.htmlhttp://cwe.mitre.org/data/definitions/89.htmlhttp://cwe.mitre.org/data/definitions/77.htmlhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)https://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/XXEhttps://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheethttps://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheethttp://www.owasp.org/index.php/Command_Injectionhttp://www.owasp.org/index.php/Injection_Flaws

7/27/2019 Owasp Top 10 2013 eBook

8/22

lication Specific ExploitabilityAVERAGE

PrevalenceWIDESPREAD


ImpactSEVERE


sidernymousrnal attackers,

well as users withr own accounts, may attempt

teal accountsm others. Alsosider insidersting to disguise

r actions.

Attacker uses leaksor flaws in theauthentication orsessionmanagementfunctions (e.g.,exposed accounts,passwords, sessionIDs) to impersonateusers.

Developers frequently build customauthentication and session managementschemes, but building these correctly ishard. As a result, these custom schemesfrequently have flaws in areas such aslogout, password management, timeouts,remember me, secret question, accountupdate, etc. Finding such flaws cansometimes be difficult, as eachimplementation is unique.

Such flaws mayallow some or evenall accounts to beattacked. Oncesuccessful, theattacker can doanything the victimcould do. Privilegedaccounts arefrequently targeted.

Consider thebusiness value ofthe affected dataapplicationfunctions.

Also consider thebusiness impact public exposure othe vulnerability.


nario #1: Airline reservations application supports URLwriting, putting session IDs in the URL:

tp://example.com/sale/saleitems;jsessionid=P0OC2JSNDLPSKHCJUN2JV ?dest=Hawaii

authenticated user of the site wants to let his friendsow about the sale. He e-mails the above link withoutowing he is also giving away his session ID. When hisnds use the link they will use his session and credit card.

nario #2: Applications timeouts arent set properly. Users a public computer to access site. Instead of selecting

gout the user simply closes the browser tab and walksay. Attacker uses the same browser an hour later, and that

wser is still authenticated.nario #3: Insider or external attacker gains access to thetems password database. User passwords are notperly hashed, exposing every users password to the

acker.

m I Vulnerable to Hijacking? session management assets like user credentials andsion IDs properly protected? You may be vulnerable if:

User authentication credentials arent protected whenstored using hashing or encryption. See A6.

Credentials can be guessed or overwritten through weakaccount management functions (e.g., account creation,change password, recover password, weak session IDs).

Session IDs are exposed in the URL (e.g., URL rewriting).

Session IDs are vulnerable to session fixation attacks.

Session IDs dont timeout, or user sessions orauthentication tokens, particularly single sign-on (SSO)tokens, arent properly invalidated during logout.

Session IDs arent rotated after successful login.

Passwords, session IDs, and other credentials are sentover unencrypted connections. See A6.

e the ASVS requirement areas V2 and V3 for more details.

References

OWASPFor a more complete set of requirements and problems toavoid in this area, see the ASVS requirements areas forAuthentication (V2) and Session Management (V3).

OWASP Authentication Cheat Sheet

OWASP Forgot Password Cheat Sheet

OWASP Session Management Cheat Sheet

OWASP Development Guide: Chapter on Authentication

OWASP Testing Guide: Chapter on Authentication

ExternalCWE Entry 287 on Improper Authentication

CWE Entry 384 on Session Fixation

How Do I Prevent This?The primary recommendation for an organization is to makeavailable to developers:

1. A single set of strong authentication and sessionmanagement controls. Such controls should strive to:

a) meet all the authentication and sessionmanagement requirements defined in OWASPsApplication Security Verification Standard (ASVS)areas V2 (Authentication) and V3 (SessionManagement).

b) have a simple interface for developers. Consider thESAPI Authenticator and User APIs as good examplto emulate, use, or build upon.

2. Strong efforts should also be made to avoid XSS flawswhich can be used to steal session IDs. See A3.

A2 Broken Authentication andSession ManagementSecurity

Weakness

Attack

VectorsTechnical

ImpactsThreatAgents

Business

Impacts
https://www.owasp.org/index.php/Session_fixationhttps://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Referencehttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/Authentication_Cheat_Sheethttps://www.owasp.org/index.php/Forgot_Password_Cheat_Sheethttps://www.owasp.org/index.php/Session_Management_Cheat_Sheethttps://www.owasp.org/index.php/Forgot_Password_Cheat_Sheethttps://www.owasp.org/index.php/Testing_for_authenticationhttp://www.owasp.org/index.php/Command_Injectionhttp://cwe.mitre.org/data/definitions/287.htmlhttp://cwe.mitre.org/data/definitions/384.htmlhttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Authenticator.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Authenticator.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Authenticator.htmlhttps://www.owasp.org/index.php/ASVShttp://cwe.mitre.org/data/definitions/384.htmlhttp://cwe.mitre.org/data/definitions/287.htmlhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/Testing_for_authenticationhttps://www.owasp.org/index.php/Forgot_Password_Cheat_Sheethttps://www.owasp.org/index.php/Session_Management_Cheat_Sheethttps://www.owasp.org/index.php/Forgot_Password_Cheat_Sheethttps://www.owasp.org/index.php/Forgot_Password_Cheat_Sheethttps://www.owasp.org/index.php/Authentication_Cheat_Sheethttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Referencehttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/Session_fixation

7/27/2019 Owasp Top 10 2013 eBook

9/22


PrevalenceVERY WIDESPREAD

DetectabilityEASY

ImpactMODERATE


sider anyone can sendusted data tosystem,uding externals, internals, andinistrators.

Attacker sends text-based attack scriptsthat exploit theinterpreter in thebrowser. Almostany source of datacan be an attackvector, includinginternal sourcessuch as data from

the database.

XSS is the most prevalent web applicationsecurity flaw. XSS flaws occur when anapplication includes user supplied data ina page sent to the browser withoutproperly validating or escaping thatcontent. There are three known types ofXSS flaws: 1) Stored, 2) Reflected, and 3)DOM based XSS.

Detection of most XSS flaws is fairly easyvia testing or code analysis.

Attackers canexecute scripts in avictims browser tohijack user sessions,deface web sites,insert hostilecontent, redirectusers, hijack theusers browserusing malware, etc.

Consider thebusiness value ofthe affected systand all the data iprocesses.


xample Attack Scenario

e application uses untrusted data in the construction of theowing HTML snippet without validation or escaping:

tring) page += "

7/27/2019 Owasp Top 10 2013 eBook

10/22


PrevalenceCOMMON

DetectabilityEASY

ImpactMODERATE


sider the typessers of yourem. Do anys have onlyial access toain types ofem data?

Attacker, who is anauthorized systemuser, simplychanges aparameter valuethat directly refersto a system objectto another objectthe user isntauthorized for. Isaccess granted?

Applications frequently use the actualname or key of an object when generatingweb pages. Applications dont alwaysverify the user is authorized for the targetobject. This results in an insecure directobject reference flaw. Testers can easilymanipulate parameter values to detectsuch flaws. Code analysis quickly showswhether authorization is properly verified.

Such flaws cancompromise all thedata that can bereferenced by theparameter. Unlessobject referencesare unpredictable,its easy for anattacker to accessall available data ofthat type.

Consider thebusiness value ofthe exposed data



e application uses unverified data in a SQL call that isessing account information:

ring query = "SELECT * FROM accts WHERE account = ?";

eparedStatement pstmt =nnection.prepareStatement(query , );

tmt.setString( 1, request.getParameter("acct"));

esultSet results = pstmt.executeQuery( );

e attacker simply modifies the acct parameter in herwser to send whatever account number she wants. If notperly verified, the attacker can access any users account,

tead of only the intended customers account.

ttp://example.com/app/accountInfo?acct=notmyacct

m I Vulnerable?e best way to find out if an application is vulnerable toecure direct object references is to verify that all objecterences have appropriate defenses. To achieve this,nsider:

For direct references to restricted resources, does theapplication fail to verify the user is authorized to accessthe exact resource they have requested?

If the reference is an indirect reference, does themapping to the direct reference fail to limit the values tothose authorized for the current user?

de review of the application can quickly verify whetherher approach is implemented safely. Testing is alsoective for identifying direct object references and whethery are safe. Automated tools typically do not look for such

ws because they cannot recognize what requirestection or what is safe or unsafe.

References

OWASPOWASP Top 10-2007 on Insecure Dir Object References

ESAPI Access Reference Map API

ESAPI Access Control API (See isAuthorizedForData(),isAuthorizedForFile(), isAuthorizedForFunction() )

For additional access control requirements, see the ASVSrequirements area for Access Control (V4).

External

CWE Entry 639 on Insecure Direct Object ReferencesCWE Entry 22 on Path Traversal(an example of a Direct ObjectReference attack)

How Do I Prevent This?Preventing insecure direct object references requiresselecting an approach for protecting each user accessibleobject (e.g., object number, filename):

1. Use per user or session indirect object references. Thisprevents attackers from directly targeting unauthorizedresources. For example, instead of using the resourcesdatabase key, a drop down list of six resourcesauthorized for the current user could use the numbers

to 6 to indicate which value the user selected. Theapplication has to map the per-user indirect referenceback to the actual database key on the server. OWASPESAPI includes both sequential and random accessreference maps that developers can use to eliminatedirect object references.

2. Check access. Each use of a direct object reference froman untrusted source must include an access control cheto ensure the user is authorized for the requested obje

Insecure Direct Object ReferencesA4Security

Weakness

Attack

VectorsTechnical

ImpactsThreatAgents

Business

Impacts
http://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Referencehttps://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Referencehttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessReferenceMap.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/AccessReferenceMap.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.htmlhttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Command_Injectionhttp://cwe.mitre.org/data/definitions/639.htmlhttp://cwe.mitre.org/data/definitions/22.htmlhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttp://cwe.mitre.org/data/definitions/22.htmlhttp://cwe.mitre.org/data/definitions/639.htmlhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/AccessReferenceMap.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessReferenceMap.htmlhttps://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Referencehttps://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Referencehttps://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Referencehttp://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference

7/27/2019 Owasp Top 10 2013 eBook

11/22


PrevalenceCOMMON

DetectabilityEASY

ImpactMODERATE


sidernymousrnal attackers

well as users withr own accountsmay attempt topromise theem. Alsosider insidersting to disguise

r actions.

Attacker accessesdefault accounts,unused pages,unpatched flaws,unprotected filesand directories, etc.to gainunauthorized accessto or knowledge ofthe system.

Security misconfiguration can happen atany level of an application stack, includingthe platform, web server, applicationserver, database, framework, and customcode. Developers and systemadministrators need to work together toensure that the entire stack is configuredproperly. Automated scanners are usefulfor detecting missing patches,misconfigurations, use of default

accounts, unnecessary services, etc.

Such flawsfrequently giveattackersunauthorized accessto some systemdata orfunctionality.Occasionally, suchflaws result in acomplete system

compromise.

The system couldbe completelycompromisedwithout youknowing it. All ofyour data could bstolen or modifieslowly over time.

Recovery costscould be expensi


nario #1: The app server admin console is automaticallytalled and not removed. Default accounts arent changed.acker discovers the standard admin pages are on yourver, logs in with default passwords, and takes over.

nario #2: Directory listing is not disabled on your server.acker discovers she can simply list directories to find any. Attacker finds and downloads all your compiled Javasses, which she decompiles and reverse engineers to get allur custom code. She then finds a serious access controlw in your application.

nario #3: App server configuration allows stack traces toreturned to users, potentially exposing underlying flaws.ackers love the extra information error messages provide.

nario #4: App server comes with sample applications thatnot removed from your production server. Said sample

plications have well known security flaws attackers can usecompromise your server.

m I Vulnerable to Attack?our application missing the proper security hardeningoss any part of the application stack? Including:

Is any of your software out of date? This includes the OS,Web/App Server, DBMS, applications, and all codelibraries (see new A9).

Are any unnecessary features enabled or installed (e.g.,ports, services, pages, accounts, privileges)?

Are default accounts and their passwords still enabled

and unchanged?Does your error handling reveal stack traces or otheroverly informative error messages to users?

Are the security settings in your development frameworks(e.g., Struts, Spring, ASP.NET) and libraries not set tosecure values?

thout a concerted, repeatable application securitynfiguration process, systems are at a higher risk.

References

OWASPOWASP Development Guide: Chapter on Configuration

OWASP Code Review Guide: Chapter on Error Handling

OWASP Testing Guide: Configuration Management

OWASP Testing Guide: Testing for Error Codes

OWASP Top 10 2004 - Insecure Configuration Managemen

For additional requirements in this area, see the ASVSrequirements area for Security Configuration (V12).

External

PC Magazine Article on Web Server Hardening

CWE Entry 2 on Environmental Security Flaws

CIS Security Configuration Guides/Benchmarks

How Do I Prevent This?The primary recommendations are to establish all of thefollowing:

1. A repeatable hardening process that makes it fast andeasy to deploy another environment that is properlylocked down. Development, QA, and productionenvironments should all be configured identically (withdifferent passwords used in each environment). Thisprocess should be automated to minimize the effortrequired to setup a new secure environment.

2. A process for keeping abreast of and deploying all newsoftware updates and patches in a timely manner to eadeployed environment. This needs to include all codelibraries as well (see new A9).

3. A strong application architecture that provides effectivesecure separation between components.

4. Consider running scans and doing audits periodically tohelp detect future misconfigurations or missing patche

Security MisconfigurationA5Security

Weakness

Attack

VectorsTechnical

ImpactsThreatAgents

Business

Impacts
http://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Referencehttps://www.owasp.org/index.php/Configurationhttps://www.owasp.org/index.php/Error_Handlinghttps://www.owasp.org/index.php/Testing_for_configuration_managementhttps://www.owasp.org/index.php/Testing_for_Error_Code_(OWASP-IG-006)https://www.owasp.org/index.php/A10_2004_Insecure_Configuration_Managementhttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Command_Injectionhttp://www.pcmag.com/article2/0,2817,11525,00.asphttp://cwe.mitre.org/data/definitions/2.htmlhttp://benchmarks.cisecurity.org/downloads/benchmarks/http://benchmarks.cisecurity.org/downloads/benchmarks/http://cwe.mitre.org/data/definitions/2.htmlhttp://www.pcmag.com/article2/0,2817,11525,00.asphttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/A10_2004_Insecure_Configuration_Managementhttps://www.owasp.org/index.php/A10_2004_Insecure_Configuration_Managementhttps://www.owasp.org/index.php/A10_2004_Insecure_Configuration_Managementhttps://www.owasp.org/index.php/A10_2004_Insecure_Configuration_Managementhttps://www.owasp.org/index.php/Testing_for_Error_Code_(OWASP-IG-006)https://www.owasp.org/index.php/Testing_for_configuration_managementhttps://www.owasp.org/index.php/Error_Handlinghttps://www.owasp.org/index.php/Configurationhttp://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference

7/27/2019 Owasp Top 10 2013 eBook

12/22

lication Specific ExploitabilityDIFFICULT

PrevalenceUNCOMMON


ImpactSEVERE


sider who canaccess to your

sitive data andbackups of that. This includes

data at rest, insit, and even inr customerswsers. Includeh external and

rnal threats.

Attackers typicallydont break cryptodirectly. They breaksomething else,such as steal keys,do man-in-the-middle attacks, orsteal clear text dataoff the server, whilein transit, or from

the users browser.

The most common flaw is simply notencrypting sensitive data. When crypto isemployed, weak key generation andmanagement, and weak algorithm usageis common, particularly weak passwordhashing techniques. Browser weaknessesare very common and easy to detect, buthard to exploit on a large scale. Externalattackers have difficulty detecting serverside flaws due to limited access and they

are also usually hard to exploit.

Failure frequentlycompromises alldata that shouldhave beenprotected. Typically,this informationincludes sensitivedata such as healthrecords, credentials,personal data,

credit cards, etc.

Consider thebusiness value ofthe lost data andimpact to yourreputation. Whatyour legal liabilitythis data isexposed? Alsoconsider thedamage to your

reputation.


nario #1: An application encrypts credit card numbers in aabase using automatic database encryption. However, thisans it also decrypts this data automatically when retrieved,

owing an SQL injection flaw to retrieve credit card numberslear text. The system should have encrypted the creditd numbers using a public key, and only allowed back-end

plications to decrypt them with the private key.

nario #2: A site simply doesnt use SSL for allhenticated pages. Attacker simply monitors networkffic (like an open wireless network), and steals the userssion cookie. Attacker then replays this cookie and hijacksusers session, accessing the users private data.

nario #3: The password database uses unsalted hashes tore everyones passwords. A file upload flaw allows anacker to retrieve the password file. All of the unsaltedhes can be exposed with a rainbow table of precalculatedhes.

m I Vulnerable to Data Exposure?e first thing you have to determine is which data issitive enough to require extra protection. For example,swords, credit card numbers, health records, and personal

ormation should be protected. For all such data:

Is any of this data stored in clear text long term, includingbackups of this data?

Is any of this data transmitted in clear text, internally orexternally? Internet traffic is especially dangerous.

Are any old / weak cryptographic algorithms used?

Are weak crypto keys generated, or is proper keymanagement or rotation missing?

Are any browser security directives or headers missingwhen sensitive data is provided by / sent to the browser?

d more For a more complete set of problems to avoid,ASVS areas Crypto (V7), Data Prot. (V9), and SSL (V10).

References

OWASP - For a more complete set of requirements, seeASVS reqts on Cryptography (V7), Data Protection (V9) andCommunications Security (V10)

OWASP Cryptographic Storage Cheat Sheet

OWASP Password Storage Cheat Sheet

OWASP Transport Layer Protection Cheat Sheet

OWASP Testing Guide: Chapter on SSL/TLS Testing

External

CWE Entry 310 on Cryptographic Issues

CWE Entry 312 on Cleartext Storage of Sensitive InformatiCWE Entry 319 on Cleartext Transmission of SensitiveInformation

CWE Entry 326 on Weak Encryption

How Do I Prevent This?The full perils of unsafe cryptography, SSL usage, and dataprotection are well beyond the scope of the Top 10. That safor all sensitive data, do all of the following, at a minimum:

1. Considering the threats you plan to protect this datafrom (e.g., insider attack, external user), make sure youencrypt all sensitive data at rest and in transit in amanner that defends against these threats.

2. Dont store sensitive data unnecessarily. Discard it as

soon as possible. Data you dont have cant be stolen. 3. Ensure strong standard algorithms and strong keys are

used, and proper key management is in place. Considerusing FIPS 140 validated cryptographic modules.

4. Ensure passwords are stored with an algorithmspecifically designed for password protection, such asbcrypt, PBKDF2, or scrypt.

5. Disable autocomplete on forms collecting sensitive datand disable caching for pages that contain sensitive dat

Sensitive Data ExposureA6Security

Weakness

Attack

VectorsTechnical

ImpactsThreatAgents

Business

Impacts
https://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storagehttps://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storagehttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storagehttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storagehttps://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheethttps://www.owasp.org/index.php/Password_Storage_Cheat_Sheethttps://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheethttps://www.owasp.org/index.php/Testing_for_SSL-TLShttp://www.owasp.org/index.php/Command_Injectionhttp://cwe.mitre.org/data/definitions/310.htmlhttp://cwe.mitre.org/data/definitions/312.htmlhttp://cwe.mitre.org/data/definitions/319.htmlhttp://cwe.mitre.org/data/definitions/319.htmlhttp://cwe.mitre.org/data/definitions/319.htmlhttp://cwe.mitre.org/data/definitions/319.htmlhttp://cwe.mitre.org/data/definitions/326.htmlhttp://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htmhttp://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htmhttp://en.wikipedia.org/wiki/Bcrypthttp://en.wikipedia.org/wiki/PBKDF2http://en.wikipedia.org/wiki/Scrypthttp://en.wikipedia.org/wiki/Bcrypthttp://en.wikipedia.org/wiki/PBKDF2http://en.wikipedia.org/wiki/Scrypthttp://en.wikipedia.org/wiki/Scrypthttp://en.wikipedia.org/wiki/PBKDF2http://en.wikipedia.org/wiki/Bcrypthttp://en.wikipedia.org/wiki/Bcrypthttp://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htmhttp://cwe.mitre.org/data/definitions/326.htmlhttp://cwe.mitre.org/data/definitions/319.htmlhttp://cwe.mitre.org/data/definitions/319.htmlhttp://cwe.mitre.org/data/definitions/319.htmlhttp://cwe.mitre.org/data/definitions/312.htmlhttp://cwe.mitre.org/data/definitions/310.htmlhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/Testing_for_SSL-TLShttps://www.owasp.org/index.php/Testing_for_SSL-TLShttps://www.owasp.org/index.php/Testing_for_SSL-TLShttps://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheethttps://www.owasp.org/index.php/Password_Storage_Cheat_Sheethttps://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheethttp://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storagehttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storagehttps://www.owasp.org/index.php/ASVS

7/27/2019 Owasp Top 10 2013 eBook

13/22


PrevalenceCOMMON


ImpactMODERATE


one withwork access cand yourication a

uest. Couldnymous usersess private

tionality orular users a

leged function?

Attacker, who is anauthorized systemuser, simplychanges the URL ora parameter to aprivileged function.Is access granted?Anonymous userscould access privatefunctions that

arent protected.

Applications do not always protectapplication functions properly.Sometimes, function level protection ismanaged via configuration, and thesystem is misconfigured. Sometimes,developers must include the proper codechecks, and they forget.

Detecting such flaws is easy. The hardestpart is identifying which pages (URLs) orfunctions exist to attack.

Such flaws allowattackers to accessunauthorizedfunctionality.Administrativefunctions are keytargets for this typeof attack.

Consider thebusiness value ofthe exposedfunctions and thedata they proces

Also consider theimpact to yourreputation if thisvulnerabilitybecame public.


nario #1: The attacker simply force browses to targetLs. The following URLs require authentication. Admin rightsalso required for access to the admin_getappInfo page.

tp://example.com/app/getappInfo

tp://example.com/app/admin_getappInfo

n unauthenticated user can access either page, thats aw. If an authenticated, non-admin, user is allowed to access

admin_getappInfopage, this is also a flaw, and mayd the attacker to more improperly protected admin pages.

nario #2: A page provides an action parameter to specifyfunction being invoked, and different actions require

erent roles. If these roles arent enforced, thats a flaw.

m I Vulnerable to Forced Access?e best way to find out if an application has failed toperly restrict function level access is to verify every

plication function:

Does the UI show navigation to unauthorized functions?

Are server side authentication or authorization checksmissing?

Are server side checks done that solely rely oninformation provided by the attacker?

ng a proxy, browse your application with a privileged role.en revisit restricted pages using a less privileged role. If thever responses are alike, you're probably vulnerable. Someting proxies directly support this type of analysis.

u can also check the access control implementation in thee. Try following a single privileged request through thee and verifying the authorization pattern. Then search theebase to find where that pattern is not being followed.

tomated tools are unlikely to find these problems.

References

OWASPOWASP Top 10-2007 on Failure to Restrict URL Access

ESAPI Access Control API

OWASP Development Guide: Chapter on Authorization

OWASP Testing Guide: Testing for Path Traversal

OWASP Article on Forced Browsing

For additional access control requirements, see the ASVSrequirements area for Access Control (V4).

ExternalCWE Entry 285 on Improper Access Control (Authorization

How Do I Prevent Forced Access?Your application should have a consistent and easy to analyauthorization module that is invoked from all of your businefunctions. Frequently, such protection is provided by one omore components external to the application code.

1. Think about the process for managing entitlements andensure you can update and audit easily. Dont hard cod

2. The enforcement mechanism(s) should deny all access default, requiring explicit grants to specific roles foraccess to every function.

3. If the function is involved in a workflow, check to makesure the conditions are in the proper state to allowaccess.

NOTE: Most web applications dont display links and buttonto unauthorized functions, but this presentation layer accecontrol doesnt actually provide protection. You must alsoimplement checks in the controller or business logic.

Missing Function Level AccessControlA7

Security

Weakness

Attack

VectorsTechnical

ImpactsThreatAgents

Business

Impacts
http://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Accesshttps://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Accesshttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.htmlhttps://www.owasp.org/index.php/Guide_to_Authorizationhttps://www.owasp.org/index.php/Testing_for_Path_Traversalhttps://www.owasp.org/index.php/Forced_browsinghttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttp://www.owasp.org/index.php/Command_Injectionhttp://cwe.mitre.org/data/definitions/285.htmlhttp://cwe.mitre.org/data/definitions/285.htmlhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/Forced_browsinghttps://www.owasp.org/index.php/Testing_for_Path_Traversalhttps://www.owasp.org/index.php/Guide_to_Authorizationhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.htmlhttps://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Accesshttps://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Accesshttps://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Accesshttp://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access

7/27/2019 Owasp Top 10 2013 eBook

14/22


PrevalenceCOMMON

DetectabilityEASY

ImpactMODERATE


sider anyone can load

tent into yours browsers,thus force them

ubmit a requestour website.website or

er HTML feedyour users

ess could do this.

Attacker createsforged HTTPrequests and tricksa victim intosubmitting them viaimage tags, XSS, ornumerous othertechniques. If theuser isauthenticated, the

attack succeeds.

CSRF takes advantage of the fact thatmost web apps allow attackers to predictall the details of a particular action.

Because browsers send credentials likesession cookies automatically, attackerscan create malicious web pages whichgenerate forged requests that areindistinguishable from legitimate ones.

Detection of CSRF flaws is fairly easy via

penetration testing or code analysis.

Attackers can trickvictims intoperforming anystate changingoperation the victimis authorized toperform, e.g.,updating accountdetails, makingpurchases, logout

and even login.

Consider thebusiness value ofthe affected dataapplicationfunctions. Imaginnot being sure ifusers intended totake these action

Consider the impto your reputatio


e application allows a user to submit a state changinguest that does not include anything secret. For example:

tp://example.com/app/transferFunds?amount=1500destinationAccount=4673243243

the attacker constructs a request that will transfer moneym the victims account to the attackers account, and thenbeds this attack in an image request or iframe stored onious sites under the attackers control:

mg src="http://example.com/app/transferFunds?mount=1500&destinationAccount=attackersAcct#

dth="0" height="0" />

he victim visits any of the attackers sites while alreadyhenticated to example.com, these forged requests willomatically include the users session info, authorizing theackers request.

m I Vulnerable to CSRF?check whether an application is vulnerable, see if any linksd forms lack an unpredictable CSRF token. Without such aen, attackers can forge malicious requests. An alternateense is to require the user to prove they intended to

bmit the request, either through reauthentication, or someer proof they are a real user (e.g., a CAPTCHA).

us on the links and forms that invoke state-changingctions, since those are the most important CSRF targets.

u should check multistep transactions, as they are noterently immune. Attackers can easily forge a series ofuests by using multiple tags or possibly JavaScript.

te that session cookies, source IP addresses, and otherormation automatically sent by the browser dont providey defense against CSRF since this information is alsouded in forged requests.

WASPs CSRF Tester tool can help generate test cases tomonstrate the dangers of CSRF flaws.

References

OWASPOWASP CSRF Article

OWASP CSRF Prevention Cheat Sheet

OWASP CSRFGuard - CSRF Defense Tool

ESAPI Project Home Page

ESAPI HTTPUtilities Class with AntiCSRF Tokens

OWASP Testing Guide: Chapter on CSRF Testing

OWASP CSRFTester - CSRF Testing Tool

ExternalCWE Entry 352 on CSRF

How Do I Prevent CSRF?Preventing CSRF usually requires the inclusion of anunpredictable token in each HTTP request. Such tokensshould, at a minimum, be unique per user session.

1. The preferred option is to include the unique token in ahidden field. This causes the value to be sent in the bodof the HTTP request, avoiding its inclusion in the URL,which is more prone to exposure.

2. The unique token can also be included in the URL itself,or a URL parameter. However, such placement runs agreater risk that the URL will be exposed to an attackerthus compromising the secret token.

OWASPs CSRF Guard can automatically include such tokensin Java EE, .NET, or PHP apps. OWASPs ESAPI includesmethods developers can use to prevent CSRF vulnerabilities

3. Requiring the user to reauthenticate, or prove they areuser (e.g., via a CAPTCHA) can also protect against CSRF

Cross-Site Request Forgery(CSRF)A8

Security

Weakness

Attack

VectorsTechnical

ImpactsThreatAgents

Business

Impacts
https://www.owasp.org/index.php/CSRFhttps://www.owasp.org/index.php/CSRFTesterhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/CSRFGuardhttps://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheethttps://www.owasp.org/index.php/CSRFGuardhttps://www.owasp.org/index.php/ESAPIhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/HTTPUtilities.htmlhttps://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005)https://www.owasp.org/index.php/CSRFTesterhttp://www.owasp.org/index.php/Command_Injectionhttp://cwe.mitre.org/data/definitions/352.htmlhttps://www.owasp.org/index.php/CSRFGuardhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/CSRFGuardhttp://cwe.mitre.org/data/definitions/352.htmlhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/CSRFTesterhttps://www.owasp.org/index.php/CSRFTesterhttps://www.owasp.org/index.php/CSRFTesterhttps://www.owasp.org/index.php/CSRFTesterhttps://www.owasp.org/index.php/Testing_for_CSRF_(OWASP-SM-005)http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/HTTPUtilities.htmlhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/CSRFGuardhttps://www.owasp.org/index.php/CSRFGuardhttps://www.owasp.org/index.php/CSRFGuardhttps://www.owasp.org/index.php/CSRFGuardhttps://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheethttps://www.owasp.org/index.php/CSRFGuardhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/CSRFTesterhttps://www.owasp.org/index.php/CSRF

7/27/2019 Owasp Top 10 2013 eBook

15/22


PrevalenceWIDESPREAD

DetectabilityDIFFICULT

ImpactMODERATE


e vulnerableponents (e.g.,

mework libraries)be identifiedexploited with

omated tools,anding theat agent pool

ond targetedckers to include

otic actors.

Attacker identifies aweak componentthrough scanning ormanual analysis. Hecustomizes theexploit as neededand executes theattack. It gets moredifficult if the usedcomponent is deep

in the application.

Virtually every application has theseissues because most development teamsdont focus on ensuring theircomponents/libraries are up to date. Inmany cases, the developers dont evenknow all the components they are using,never mind their versions. Componentdependencies make things even worse.

The full range ofweaknesses ispossible, includinginjection, brokenaccess control, XSS,etc. The impactcould range fromminimal tocomplete hosttakeover and data

compromise.

Consider what eavulnerability migmean for thebusiness controllby the affectedapplication. It cobe trivial or it coumean completecompromise.


mponent vulnerabilities can cause almost any type of riskaginable, ranging from the trivial to sophisticated malwareigned to target a specific organization. Components

most always run with the full privilege of the application, sows in any component can be serious, The following twonerable components were downloaded 22m times in 2011.

Apache CXF Authentication Bypass By failing to providean identity token, attackers could invoke any web servicewith full permission. (Apache CXF is a services framework,not to be confused with the Apache Application Server.)

Spring Remote Code Execution Abuse of the ExpressionLanguage implementation in Spring allowed attackers toexecute arbitrary code, effectively taking over the server.

ry application using either of these vulnerable libraries isnerable to attack as both of these components are directlyessible by application users. Other vulnerable libraries,d deeper in an application, may be harder to exploit.

m I Vulnerable to Known Vulns?heory, it ought to be easy to figure out if you are currentlyng any vulnerable components or libraries. Unfortunately,nerability reports for commercial or open source softwarenot always specify exactly which versions of a componentvulnerable in a standard, searchable way. Further, not allaries use an understandable version numbering system.rst of all, not all vulnerabilities are reported to a central

aringhouse that is easy to search, although sites like CVEd NVD are becoming easier to search.

termining if you are vulnerable requires searching theseabases, as well as keeping abreast of project mailing lists

d announcements for anything that might be anerability. If one of your components does have anerability, you should carefully evaluate whether you areually vulnerable by checking to see if your code uses thet of the component with the vulnerability and whether the

w could result in an impact you care about.

References

OWASPOWASP Dependency Check (for Java libraries)

OWASP SafeNuGet (for .NET libraries thru NuGet)

Good Component Practices Project

External

The Unfortunate Reality of Insecure Libraries

Open Source Software Security

Addressing Security Concerns in Open Source Components

MITRE Common Vulnerabilities and Exposures

Example Mass Assignment Vulnerability that was fixed inActiveRecord, a Ruby on Rails GEM

How Do I Prevent This?One option is not to use components that you didnt write.But thats not very realistic.

Most component projects do not create vulnerability patchfor old versions. Instead, most simply fix the problem in thenext version. So upgrading to these new versions is critical.Software projects should have a process in place to:

1) Identify all components and the versions you are using,including all dependencies. (e.g., the versions plugin).

2) Monitor the security of these components in publicdatabases, project mailing lists, and security mailing listand keep them up to date.

3) Establish security policies governing component use,such as requiring certain software developmentpractices, passing security tests, and acceptable license

4) Where appropriate, consider adding security wrappersaround components to disable unused functionality andor secure weak or vulnerable aspects of the componen

Using Components with KnownVulnerabilitiesA9

Security

Weakness

Attack

VectorsTechnical

ImpactsThreatAgents

Business

Impacts
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3451http://www.infosecurity-magazine.com/view/30282/remote-code-vulnerability-in-spring-framework-for-java/http://cve.mitre.org/http://nvd.nist.gov/home.cfmhttp://cve.mitre.org/http://nvd.nist.gov/home.cfmhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/OWASP_Dependency_Checkhttps://github.com/OWASP/SafeNuGethttps://www.owasp.org/index.php/OWASP_Good_Component_Practices_Projecthttp://www.owasp.org/index.php/Command_Injectionhttps://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdfhttp://en.wikipedia.org/wiki/Open_source_software_securityhttp://www.sonatype.com/content/download/1025/10060/file/sonatype_executive_security_brief_final.pdfhttp://cve.mitre.org/http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0277http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0277http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0277http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0277http://mojo.codehaus.org/versions-maven-plugin/http://mojo.codehaus.org/versions-maven-plugin/http://mojo.codehaus.org/versions-maven-plugin/http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0277http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0277http://cve.mitre.org/http://www.sonatype.com/content/download/1025/10060/file/sonatype_executive_security_brief_final.pdfhttp://en.wikipedia.org/wiki/Open_source_software_securityhttps://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdfhttp://www.owasp.org/index.php/Command_Injectionhttps://www.owasp.org/index.php/OWASP_Good_Component_Practices_Projecthttps://github.com/OWASP/SafeNuGethttps://github.com/OWASP/SafeNuGethttps://github.com/OWASP/SafeNuGethttps://github.com/OWASP/SafeNuGethttps://github.com/OWASP/SafeNuGethttps://github.com/OWASP/SafeNuGethttps://www.owasp.org/index.php/OWASP_Dependency_Checkhttp://www.owasp.org/index.php/Command_Injectionhttp://nvd.nist.gov/home.cfmhttp://cve.mitre.org/http://www.infosecurity-magazine.com/view/30282/remote-code-vulnerability-in-spring-framework-for-java/http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3451

7/27/2019 Owasp Top 10 2013 eBook

16/22


PrevalenceUNCOMMON

DetectabilityEASY

ImpactMODERATE


sider anyone can trick yours into

mitting auest to yoursite. Anysite or other

ML feed thatr users used do this.

Attacker links tounvalidated redirectand tricks victimsinto clicking it.Victims are morelikely to click on it,since the link is to avalid site. Attackertargets unsafeforward to bypass

security checks.

Applications frequently redirect users toother pages, or use internal forwards in asimilar manner. Sometimes the targetpage is specified in an unvalidatedparameter, allowing attackers to choosethe destination page.

Detecting unchecked redirects is easy.Look for redirects where you can set thefull URL. Unchecked forwards are harder,because they target internal pages.

Such redirects mayattempt to installmalware or trickvictims intodisclosingpasswords or othersensitiveinformation. Unsafeforwards may allowaccess control

bypass.

Consider thebusiness value ofretaining yourusers trust.

What if they getowned by malwa

What if attackerscan access internonly functions?


nario #1: The application has a page called redirect.jspich takes a single parameter named url. The attackerfts a malicious URL that redirects users to a malicious sitet performs phishing and installs malware.

tp://www.example.com/redirect.jsp?url=evil.com

nario #2: The application uses forwards to route requestsween different parts of the site. To facilitate this, some

ges use a parameter to indicate where the user should bet if a transaction is successful. In this case, the attackerfts a URL that will pass the applications access controlck and then forwards the attacker to administrativectionality for which the attacker isnt authorized.

tp://www.example.com/boring.jsp?fwd=admin.jsp

m I Vulnerable to Redirection?e best way to find out if an application has any unvalidatedirects or forwards is to:

Review the code for all uses of redirect or forward (calleda transfer in .NET). For each use, identify if the target URLis included in any parameter values. If so, if the targetURL isnt validated against a whitelist, you are vulnerable.

Also, spider the site to see if it generates any redirects(HTTP response codes 300-307, typically 302). Look atthe parameters supplied prior to the redirect to see ifthey appear to be a target URL or a piece of such a URL. Ifso, change the URL target and observe whether the siteredirects to the new target.

If code is unavailable, check all parameters to see if theylook like part of a redirect or forward URL destination andtest those that do.

References

OWASPOWASP Article on Open Redirects

ESAPI SecurityWrapperResponse sendRedirect() method

External

CWE Entry 601 on Open Redirects

WASC Article on URL Redirector Abuse

Google blog article on the dangers of open redirects

OWASP Top 10 for .NET article on Unvalidated Redirects a

Forwards

How Do I Prevent This?Safe use of redirects and forwards can be done in a numberof ways:

1. Simply avoid using redirects and forwards.

2. If used, dont involve user parameters in calculating thedestination. This can usually be done.

3. If destination parameters cant be avoided, ensure thatthe supplied value is valid, and authorized for the user

It is recommended that any such destination parametebe a mapping value, rather than the actual URL orportion of the URL, and that server side code translatethis mapping to the target URL.

Applications can use ESAPI to override the sendRedirecmethod to make sure all redirect destinations are safe.

Avoiding such flaws is extremely important as they are afavorite target of phishers trying to gain the users trust.

Unvalidated Redirects andForwardsA10

Security

Weakness

Attack

VectorsTechnical

ImpactsThreatAgents

Business

Impacts
http://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Accesshttps://www.owasp.org/index.php/Open_redirecthttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/filters/SecurityWrapperResponse.htmlhttp://www.owasp.org/index.php/Command_Injectionhttp://cwe.mitre.org/data/definitions/601.htmlhttp://projects.webappsec.org/URL-Redirector-Abusehttp://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your-site-being.htmlhttp://www.troyhunt.com/2011/12/owasp-top-10-for-net-developers-part-10.htmlhttp://www.troyhunt.com/2011/12/owasp-top-10-for-net-developers-part-10.htmlhttp://www.troyhunt.com/2011/12/owasp-top-10-for-net-developers-part-10.htmlhttp://www.troyhunt.com/2011/12/owasp-top-10-for-net-developers-part-10.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/filters/SecurityWrapperResponse.htmlhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/filters/SecurityWrapperResponse.htmlhttp://www.troyhunt.com/2011/12/owasp-top-10-for-net-developers-part-10.htmlhttp://www.troyhunt.com/2011/12/owasp-top-10-for-net-developers-part-10.htmlhttp://www.troyhunt.com/2011/12/owasp-top-10-for-net-developers-part-10.htmlhttp://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your-site-being.htmlhttp://projects.webappsec.org/URL-Redirector-Abusehttp://cwe.mitre.org/data/definitions/601.htmlhttp://cwe.mitre.org/data/definitions/601.htmlhttp://www.owasp.org/index.php/Command_Injectionhttp://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/filters/SecurityWrapperResponse.htmlhttps://www.owasp.org/index.php/Open_redirecthttp://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access

7/27/2019 Owasp Top 10 2013 eBook

17/22

tablish & Use Repeatable Security Processes and Standard Security Controls

ether you are new to web application security or are already very familiar with these risks, the task of producing a secure we

plication or fixing an existing one can be difficult. If you have to manage a large application portfolio, this can be daunting.

help organizations and developers reduce their application security risks in a cost effective manner, OWASP has produced

merous free and open resources that you can use to address application security in your organization. The following are som

he many resources OWASP has produced to help organizations produce secure web applications. On the next page, we

sent additional OWASP resources that can assist organizations in verifying the security of their applications.

ere are numerous additional OWASP resources available for your use. Please visit the OWASP Projects page, which lists all of

OWASP projects, organized by the release quality of the projects in question (Release Quality, Beta, or Alpha). Most OWASP

ources are available on our wiki, and many OWASP documents can be ordered in hardcopy or as eBooks.

Whats Next for Developers+D

To produce a secure web application, you must define what secure means for that application.

OWASP recommends you use the OWASP Application Security Verification Standard (ASVS), as aguide for setting the security requirements for your application(s). If youre outsourcing, considerthe OWASP Secure Software Contract Annex.

Application

SecurityRequirements

Rather than retrofitting security into your applications, it is far more cost effective to design thesecurity in from the start. OWASP recommends the OWASP Developers Guide, and the OWASPPrevention Cheat Sheets as good starting points for guidance on how to design security in fromthe beginning.

ApplicationSecurity

Architecture

Building strong and usable security controls is exceptionally difficult. A set of standard securitycontrols radically simplifies the development of secure applications. OWASP recommends theOWASP Enterprise Security API (ESAPI) project as a model for the security APIs needed to producesecure web applications. ESAPI provides reference implementations in Java, .NET, PHP, ClassicASP, Python, and Cold Fusion.

StandardSecurityControls

To improve the process your organization follows when building such applications, OWASPrecommends the OWASP Software Assurance Maturity Model (SAMM). This model helpsorganizations formulate and implement a strategy for software security that is tailored to thespecific risks facing their organization.

SecureDevelopment

Lifecycle

The OWASP Education Project provides training materials to help educate developers on webapplication security and has compiled a large list ofOWASP Educational Presentations. For hands-on learning about vulnerabilities, try OWASP WebGoat, WebGoat.NET, or the OWASP Broken WebApplications Project. To stay current, come to an OWASP AppSec Conference, OWASP ConferenceTraining, or local OWASP Chapter meetings.

ApplicationSecurity

Education
https://www.owasp.org/index.php/Projectshttps://www.owasp.org/http://stores.lulu.com/owasphttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annexhttps://www.owasp.org/index.php/OWASP_Guide_Projecthttps://www.owasp.org/index.php/Cheat_Sheetshttps://www.owasp.org/index.php/Cheat_Sheetshttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/SAMMhttp://www.owasp.org/index.php/SAMMhttps://www.owasp.org/index.php/Category:OWASP_Education_Projecthttps://www.owasp.org/index.php/OWASP_Education_Presentationhttps://www.owasp.org/index.php/WebGoathttps://www.owasp.org/index.php/Category:OWASP_WebGoat.NEThttps://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Projecthttps://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Projecthttps://www.owasp.org/index.php/Category:OWASP_AppSec_Conferencehttps://www.owasp.org/index.php/Category:OWASP_Chapterhttps://www.owasp.org/index.php/Category:OWASP_Chapterhttps://www.owasp.org/index.php/Category:OWASP_AppSec_Conferencehttps://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Projecthttps://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Projecthttps://www.owasp.org/index.php/Category:OWASP_WebGoat.NEThttps://www.owasp.org/index.php/WebGoathttps://www.owasp.org/index.php/OWASP_Education_Presentationhttps://www.owasp.org/index.php/Category:OWASP_Education_Projecthttp://www.owasp.org/index.php/SAMMhttps://www.owasp.org/index.php/SAMMhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/Cheat_Sheetshttps://www.owasp.org/index.php/Cheat_Sheetshttps://www.owasp.org/index.php/OWASP_Guide_Projecthttps://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annexhttps://www.owasp.org/index.php/ASVShttp://stores.lulu.com/owasphttps://www.owasp.org/https://www.owasp.org/index.php/Projects

7/27/2019 Owasp Top 10 2013 eBook

18/22

et Organized

verify the security of a web application you have developed, or one you are considering purchasing, OWASP recommends th

u review the applications code (if available), and test the application as well. OWASP recommends a combination of secure

e review and application penetration testing whenever possible, as that allows you to leverage the strengths of both

hniques, and the two approaches complement each other. Tools for assisting the verification process can improve the

ciency and effectiveness of an expert analyst. OWASPs assessment tools are focused on helping an expert become more

ective, rather than trying to automate the analysis process itself.

ndardizing How You Verify Web Application Security: To help organizations develop consistency and a defined level of rigor

en assessing the security of web applications, OWASP has produced the OWASP Application Security Verification Standard

VS). This document defines a minimum verification standard for performing web application security assessments. OWASP

ommends that you use the ASVS as guidance for not only what to look for when verifying the security of a web application,

also which techniques are most appropriate to use, and to help you define and select a level of rigor when verifying the

urity of a web application. OWASP also recommends you use the ASVS to help define and select any web application

essment services you might procure from a third party provider.

essment Tools Suite: The OWASP Live CD Project has pulled together some of the best open source security tools into a sing

otable environment or virtual machine (VM). Web developers, testers, and security professionals can boot from this Live CD,

run the VM, and immediately have access to a full security testing suite. No installation or configuration is required to use th

ls provided on this CD.

Whats Next for Verifiers+V

ode Review

ure code review is particularly suited to verifying that an

plication contains strong security mechanisms as well as

ding issues that are hard to identify by examining the

plications output. Testing is particularly suited to proving

t flaws are actually exploitable. That said, the approaches

complementary and in fact overlap in some areas.

viewing the Code: As a companion to the OWASP

velopers Guide, and the OWASP Testing Guide, OWASP has

duced the OWASP Code Review Guide to help developers

d application security specialists understand how to

ciently and effectively review a web application for security

reviewing the code. There are numerous web application

urity issues, such as Injection Flaws, that are far easier to

d through code review, than external testing.

de Review Tools: OWASP has been doing some promising

rk in the area of assisting experts in performing code

alysis, but thes

owasp top 10 2013 ebook

Documents