owasp top 10 - 2013 english

7/27/2019 OWASP Top 10 - 2013 English

1/23


2/23

Release Candidate

Important Notice

RC

Request for Comments

OWASP plans to release the final public release of the OWASP Top 10 - 2013 in April or May 2013 after apublic comment period ending March 30, 2013.

This release of the OWASP Top 10 marks this projects tenth year of raising awareness of the importance

of application security risks. This release follows the 2010 updates focus on risk, detailing the threats,

attacks, weaknesses, security controls, technical impacts, and business impacts associated with each risk.

Using this approach, we believe this provides a model for how organizations can think beyond the ten

risks here and figure out the most important risks that their applications create for their business.

Following the final publication of the OWASP Top 10 - 2013, the collaborative work of the OWASP

community will continue with updates to supporting documents including the OWASP wiki, OWASP

Developers Guide, OWASP Testing Guide, OWASP Code Review Guide, and the OWASP Prevention CheatSheet Series.

Constructive comments on this OWASP Top 10 - 2013 Release Candidate should be forwarded via email to

[email protected]. Private comments may be sent to [email protected].

Anonymous comments are welcome. All non-private comments will be catalogued and published at the

same time as the final public release. Comments recommending changes to the items listed in the Top 10

should include a complete suggested list of 10 items, along with a rationale for any changes. All comments

should indicate the specific relevant page and section.

Your feedback is critical to the continued success of the OWASP Top 10 Project. Thank you all for your

dedication to improving the security of the worlds software for everyone.

Jeff Williams, OWASP Top 10 Project Creator and Coauthor

Dave Wichers, OWASP Top 10 Project Lead
mailto:[email protected]:[email protected]:[email protected]:[email protected]


3/23

O About OWASP

opyright and License

Copyright 20032013 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 eleventh year 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 in a

cess model. Instead, leverage your existing organizations

engths and measure what works for you.

hope that the OWASP Top 10 is useful to your applicationurity efforts. Please dont hesitate to contact OWASP with

ur questions, comments, and ideas, either publicly to

[email protected] 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 findfree and open

Application security tools and standards

Complete books on application security testing, secure

code development, and security code review

Standard security controls and libraries

Local chapters worldwide

Cutting edge research

Extensive conferences worldwide

Mailing lists

And more all at www.owasp.org/

Including: www.owasp.org/index.php/Top_10

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/https://www.owasp.org/index.php/Top_10https://www.owasp.org/index.php/Top_10https://www.owasp.org/mailto:[email protected]:[email protected]:[email protected]:[email protected]://www.owasp.org/index.php/Industry:Citationshttp://creativecommons.org/licenses/by-sa/3.0/


4/23

Welcome

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

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 is based on risk data from 8 firms that specialize in application security, including 4 consulting companies an

ool vendors (2 static and 2 dynamic). This data spans over 500,000 vulnerabilities across hundreds of organizations and

usands of applications. The Top 10 items are selected and prioritized according to this prevalence data, in combination with

nsensus 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 areasand 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. This is essential reading for

yone developing web applications today. Guidance on how

effectively find vulnerabilities in web applications are

vided in the OWASP Testing Guideand OWASP Code

view Guide, which have both been significantly updatedce the previous release of the OWASP Top 10.

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. Please

iew the advice at the end of the Top 10 in Whats Next

Developers, Verifiers, and Organizations for more

ormation.

nk positive. When youre ready to stop chasing

nerabilities and focus on establishing strong applicationurity controls, OWASP has produced the Application

urity 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 outre in the Open Software Assurance Maturity Model

MM)and the Rugged Handbook.

Acknowledgements

Thanks to Aspect Securityfor 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 Security

HP(Results for both Fortify and WebInspect)

Minded Security

Softtek

TrustWave

VeracodeStatistics

WhiteHat Security Inc.Statistics

I Introduction
https://www.owasp.org/index.php/OWASP_Guide_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/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/http://www.hpenterprisesecurity.com/http://www.mindedsecurity.com/http://www.softtek.com/https://www.trustwave.com/http://www.veracode.com/http://info.veracode.com/rs/veracode/images/VERACODE-SOSS-V4.PDFhttps://www.whitehatsec.com/https://www.whitehatsec.com/home/resource/stats.htmlhttps://www.whitehatsec.com/home/resource/stats.htmlhttps://www.whitehatsec.com/http://info.veracode.com/rs/veracode/images/VERACODE-SOSS-V4.PDFhttp://www.veracode.com/https://www.trustwave.com/http://www.softtek.com/http://www.mindedsecurity.com/http://www.hpenterprisesecurity.com/https://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_Code_Review_Projecthttps://www.owasp.org/index.php/Category:OWASP_Testing_Projecthttps://www.owasp.org/index.php/OWASP_Guide_Project


5/23

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,. Probably because this are

is being looked at harder, not because 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 Controlto 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-A6Security Misconfiguration, but now deserves a category in its own right

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

components.

OWASP Top 102010 (Previous) OWASP Top 102013 (New)

Injection A1Injection

Broken Authentication and Session Management A2Broken Authentication and Session Management

Cross-Site Scripting (XSS) A3Cross-Site Scripting (XSS)

Insecure Direct Object References A4Insecure Direct Object References

Security Misconfiguration A5Security Misconfiguration

Insecure Cryptographic StorageMerged with A9 A6Sensitive Data Exposure

Failure to Restrict URL AccessBroadened into A7Missing Function Level Access Control

Cross-Site Request Forgery (CSRF) A8Cross-Site Request Forgery (CSRF)

uried in A6: Security Misconfiguration> A9Using Known Vulnerable Components

0Unvalidated Redirects and Forwards A10Unvalidated Redirects and Forwards

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

Release NotesRN


6/23

Weakness

Attack

ThreatAgents

ImpactWeakness

Attack

AttackVectors

SecurityWeaknesses

TechnicalImpacts

BusinessImpacts

Attack

Impact

Impact

Asset

Function

Asset

Weakness

Control

Control

ControlWeakness

SecurityControls

Threat

Agent

Attack

Vector

Weakness

Prevalence

Weakness

Detectability

Technical

Impact

Business

Impact

?Easy Widespread Easy Severe

?Average Common Average ModerateDifficult Uncommon Difficult Minor

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 10focuses on identifying the most serious risks for a broad arrayorganizations. For each of these risks, we provide generic information aboutlihood andtechnical 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. Therefore, you shouldluate each risk for yourself, focusing on the threat agents, security controls, and

siness impacts in your enterprise.

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 the name that is best known

d will achieve the highest level of 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 range from nothing, all the way through putting you out of business. To determine the risk to your organization, yo evaluate the likelihood associated with each threat agent, attack vector, and security weakness and combine it with anmate of the technical and business impact to your organization. Together, these factors determine the overall risk.
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/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/23

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 unauthorized data.

A1Injection

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

A2BrokenAuthentication 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.

A3Cross-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.

A4InsecureDirect ObjectReferences

Good security requires having a secure configuration defined and deployed for the application,frameworks, application server, web server, database server, and platform. All these settingsshould be defined, implemented, and maintained as many are not shipped with secure defaults.This includes keeping all software up to date.

A5SecurityMisconfiguration

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 conductidentity theft, credit card fraud, or other crimes. Sensitive data deserves extra protection such asencryption at rest or in transit, as well as special precautions when exchanged with the browser.

A6Sensitive DataExposure

Virtually all web applications verify function level access rights before making that functionalityvisible in the UI. However, applications need to perform the same access control checks on theserver when each function is accessed. If requests are not verified, attackers will be able to forgerequests in order to access unauthorized functionality.

A7MissingFunction 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 generate

requests the vulnerable application thinks are legitimate requests from the victim.

A8 - Cross-SiteRequest Forgery

(CSRF)

Vulnerable components, such as libraries, frameworks, and other software modules almostalways run with full privilege. So, if exploited, they can cause serious data loss or server takeoverApplications using these vulnerable components may undermine their defenses and enable arange 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.

A10Unvalidated

Redirects andForwards

OWASP Top 10 ApplicationSecurity Risks2013T10


8/23

? ExploitabilityEASY

PrevalenceCOMMON

DetectabilityAVERAGE

ImpactSEVERE

?

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 flawsoccur when an applicationsends untrusted data to an interpreter.Injection flaws are very prevalent,particularly in legacy code. They are oftenfound in SQL, LDAP, or XPath queries, OScommands, XML parsers, programarguments, etc. Injection flaws are easy todiscover when examining code, but moredifficult via testing. Scanners and fuzzerscan help attackers find them.

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 Scenario

e application uses untrusted data in the construction of theowing vulnerable SQL call:

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

e attacker modifies the id parameter in their browser tod: ' or '1'='1. This changes the meaning of the query to

urn all the records from the accounts database, instead ofy the intended customers.

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

he worst case, the attacker uses this weakness to invokecial stored procedures in the database that enable a

mplete takeover of the database and possibly even thever hosting the database.

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 of APIs, such asstored procedures, that are parameterized, but can stilintroduce injection under the hood.

2. If a parameterized API is not available, you shouldcarefully escape special characters using the specificescape syntax for that interpreter. OWASPs ESAPIprovides many of these escaping routines.

3. Positive or white list input validation with appropriatecanonicalization is also recommended, but is not acomplete defense as many applications require specialcharacters in their input. OWASPs ESAPIhas anextensible library of white 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


9/23

? 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.

xample Attack Scenarios

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 notcrypted, exposing every users password to the attacker.

m I Vulnerable to Hijacking?e primary assets to protect are credentials and session IDs.

Are credentials always protected when stored usinghashing or encryption? See A6.

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

Are session IDs exposed in the URL (e.g., URL rewriting)?

Are session IDs vulnerable to session fixationattacks?

Do session IDs timeout and can users log out?

Are session IDs rotated after successful login?

Are passwords, session IDs, and other credentials sentonly over TLS connections? See A6.

e the ASVSrequirement areas V2 and V3 for more details.

References

OWASPFor a more complete set of requirements and problemstoavoid 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 APIsas 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


10/23


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.

XSSis 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.



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

tring) page += "


11/23


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 and code analysis quicklyshows whether authorization is properlyverified.

Such flaws cancompromise all thedata that can bereferenced by theparameter. Unlessthe name space issparse, its easy foran attacker toaccess all availabledata of that 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 theirwser to send whatever account number they want. If notified, the attacker can access any users account, instead

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, theapplication needs to verify the user is authorized toaccess the exact resource they have requested.

If the reference is an indirect reference, the mapping tothe direct reference must be limited to values authorizedfor 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(which is an example of a DirectObject Reference 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. OWASPESAPIincludes 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


12/23


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, framework, and custom code.Developers and network administratorsneed to work together to ensure that theentire stack is configured properly.Automated scanners are useful fordetecting 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 yodata could be stoor modified slowover 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 reverses to get all your custom code. Shen finds a serious access control flaw 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 sampleplications have well known security flaws attackers can usecompromise your server.

m I Vulnerable to Attack?ve you performed the proper security hardening across theire application stack?

Do you have a process for keeping all your software up todate? This includes the OS, Web/App Server, DBMS,applications, and all code libraries (see new A9).

Is everything unnecessary disabled, removed, or notinstalled (e.g. ports, services, pages, accounts, privileges)?

Are default account passwords changed or disabled?

Is your error handling set up to prevent stack traces andother overly informative error messages from leaking?

Are the security settings in your development frameworks(e.g., Struts, Spring, ASP.NET) and libraries understoodand configured properly?

oncerted, repeatable process is required to develop andintain a proper application security configuration.

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. 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 goodseparation and security 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


13/23

? 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 a man-in-the-middle attack, stealclear text data offthe server, steal itin transit, or right

from the browser.

The most common flaw is simply notencrypting sensitive data. When crypto isemployed, weak key generation andmanagement, and weak algorithm usageis common, particularly weak hashingsolutions to protect passwords. Browserweaknesses are very common and easy todetect, but hard to exploit. Externalattackers have difficulty detecting most ofthese types of flaws due to limited access

and they are also usually hard to exploit.

Failure frequentlycompromises alldata that shouldhave beenprotected. Typicallythis 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 all their 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 the unsalted hashes be exposed with a rainbow table of precalculated hashes.

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, ensure:

It is encrypted everywhere it is stored long term,including backups of this data.

It is encrypted in transit, ideally internally as well asexternally. All internet traffic should be encrypted.

Strong encryption algorithms are used for all crypto.

Strong crypto keys are generated, and proper keymanagement is in place, including key rotation.

Proper browser directives and headers are set to protectsensitive data provided by or sent to the browser.

dmore 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 areused, and proper key management is in place.

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 displaying sensitive data.

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://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://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


14/23


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 proper authentication and authorization checked?

Are checks done on the server without relying oninformation provided by the attacker?

ng a proxy, browse your application with a privileged role.en revisit restricted pages while logged in as a lessvileged role. Some proxies 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 toure that the pattern is followed throughout.

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 easilyanalyzable authorization module that is invoked from all yobusiness functions. Frequently, such protection is providedby one or more components external to the application cod

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


15/23


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.

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

Since 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 causevictims to changeany data the victimis allowed to changeor perform anyother function thevictim is authorizedto use, includingstate changingrequests, like logout

or 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 their account, and then embedss attack in an image request or iframe stored on variouses under the attackers control like so:

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 each linkd form includes an unpredictable 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 doesnt countce this information is also included in forged requests.

WASPs CSRF Testertool 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 subject to exposure.

2. The unique token can also be included in the URL itself,or a URL parameter. However, such placement runs therisk that the URL will be exposed to an attacker, thuscompromising the secret token.

OWASPs CSRF Guardcan automaticallyinclude such tokensin Java EE, .NET, or PHP apps. OWASPs ESAPIincludes CSRFmethods developers can use to prevent such 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


16/23


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.They customize theexploit as neededand execute theattack. It gets moredifficult if the usedcomponent is deep

in the application.

Virtually every application has theseissues because most development teamsdont focus on ensuring their componentsstay up to date. In many cases, thedevelopers dont even know all thecomponents they are using, never mindtheir versions. Component dependenciesmake things even worse.

The full range ofweaknesses ispossible, includinginjection, brokenaccess control, XSS,etc. The impactcould be minimal,up to complete hosttakeover and datacompromise.

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, 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 BypassBy failing to providean identity token, attackers could invoke any web servicewith full permission.

Spring Remote Code ExecutionAbuse 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 do not always specify exactly whichsions of a component are vulnerable in a standard,rchable way. Further, not all libraries use an

derstandable version numbering system. Worst of all, notvulnerabilities are reported to a central clearinghouse thatasy to search, although sites like CVEand NVDare

coming 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

OWASPNone

External

The Unfortunate Reality of Insecure Libraries

Open Source Software Security

Addressing Security Concerns in Open Source Components

MITRE Common Vulnerabilities and Exposures

How Do I Prevent This?One option is not to use components that you didnt write.But realistically, the best way to deal with this risk is to ensuthat you keep your components up-to-date.

Many open source projects (and other component sources)do not create vulnerability patches for old versions. Insteadmost simply fix the problem in the next version.

Software projects should have a process in place to:

1) Identify the components and their versions you are usinincluding all dependencies. (e.g., the versionsplugin).

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

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_Injectionhttp://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://mojo.codehaus.org/versions-maven-plugin/http://mojo.codehaus.org/versions-maven-plugin/http://mojo.codehaus.org/versions-maven-plugin/http://cve.mitre.org/http://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_Injectionhttp://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


17/23


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,since 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 an administrativection that she would not normally be able to access.

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, verify theparameter(s) are validated to contain only an alloweddestination, or element of a destination.

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


18/23

tablish and Use a Full Set of Common 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.

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 Sheetsas good starting points for guidance on how to design security in fromthe beginning.

ApplicationSecurity

Architecture

Building strong and usable security controls is exceptionally difficult. Providing developers with aset of standard security controls radically simplifies the development of secure applications.OWASP recommends the OWASP Enterprise Security API (ESAPI) projectas a model for thesecurity APIs needed to produce secure web applications. ESAPI provides referenceimplementations in Java, .NET, PHP, Classic ASP, 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 Projectprovides training materials to help educate developers on webapplication security and has compiled a large list of OWASP Educational Presentations. Forhands-on learning about vulnerabilities, try OWASP WebGoat, WebGoat.NET, or the OWASPBroken Web Applications Project. To stay current, come to an OWASP AppSec Conference,OWASP Conference Training, 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/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/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


19/23

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 security

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 Projecthas pulled together some of the best open source security tools into a sing

otable environment. Web developers, testers, and security professionals can boot from this Live CD and immediately have

ess to a full security testing suite. No installation or configuration is required to use the tools provided on this CD.

Whats Next for Verifiers+V

ode Review

viewing the code is the strongest way to verify whether an

plication is secure. Testing can only prove that an

plication is insecure.

viewing the Code: As a companion to the OWASP

velopers Guide, and the OWASP Testing Guide, OWASP has

duced the OWASP Code Review Guideto 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 tod 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 these tools are still in their early stages. The

hors of these tools use them every day when performing

ir security code reviews, but non-experts may find these

ls a bit difficult to use. These include CodeCrawler, Orizon,

d O2. Only O2has been under active development during

past three years.

ere are other free, open source, code review tools. The

st promising is FindBugs, and its new security focused

gin called: FindSecurityBugs, both of which are for Java.

Security and Penetration Testing

Testing the Application: OWASP produced the Testing Guid

to help developers, testers, and application security

specialists understand how to efficiently and effectively tes

the security of web applications. This enormous guide, whi

had dozens of contributors, provides wide coverage on ma

web application security testing topics. Just as code review

has its strengths, so does security testing. Its very compelli

when you can prove that an application is insecure by

demonstrating the exploit. There are also many security

issues, particularly all the security provided by the

application infrastructure, that simply cannot be seen by acode review, since the application is not providing the

security itself.

Application Penetration Testing Tools: WebScarab, which

was one of the most widely used of all OWASP projects, an

the new ZAP, which now is far more popular, are both web

application testing proxies. They allow security analysts to

intercept web application requests, so the analyst can figur

out how the application works, and then allow the analyst t

submit test requests to see if the application responds

securely to such requests. These tools are particularlyeffective at assisting an analyst in identifying XSS flaws,

Authentication flaws, and Access Control flaws. ZAPeven h

an active scannerbuilt in, and best of all its FREE!
https://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/ASVShttps://www.owasp.org/index.php/Category:OWASP_Live_CD_Projecthttps://www.owasp.org/index.php/OWASP_Guide_Projecthttps://www.owasp.org/index.php/OWASP_Guide_Projecthttps://www.owasp.org/index.php/OWASP_Testing_Projecthttps://www.owasp.org/index.php/Code_Review_Guidehttps://www.owasp.org/index.php/Category:OWASP_Code_Crawlerhttps://www.owasp.org/index.php/Category:OWASP_Orizon_Projecthttps://www.owasp.org/index.php/OWASP_O2_Platformhttps://www.owasp.org/index.php/OWASP_O2_Platformhttp://findbugs.sourceforge.net/index.htmlhttp://h3xstream.github.com/find-sec-bugs/https://www.owasp.org/index.php/OWASP_Testing_Projecthttps://www.owasp.org/index.php/WebScarabhttps://www.owasp.org/index.php/ZAPhttps://www.owasp.org/index.php/ZAPhttp://code.google.com/p/zaproxy/wiki/HelpStartConceptsAscanhttp://code.google.com/p/zaproxy/wiki/HelpStartConceptsAscanhttps://www.owasp.org/index.php/ZAPhttps://www.owasp.org/index.php/ZAPhttps://www.owasp.org/index.php/WebScarabhttps://www.owasp.org/index.php/OWASP_Testing_Projecthttp://h3xstream.github.com/find-sec-bugs/http://findbugs.sourceforge.net/index.htmlhttps://www.owasp.org/index.php/OWASP_

owasp top 10 - 2013 english

Documents