OWASP Web Application Penetration Checklist
Version 1.1

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.

Introduction......................................................................................................................... 3
Using this Checklist as an RFP Template....................................................................... 3
Using this Checklist as a Benchmark.............................................................................. 3
Using this Checklist as a Checklist................................................................................. 4
About the OWASP Testing Project (Parts One and Two).............................................. 4
The OASIS WAS Standard............................................................................................. 4
About OWASP................................................................................................................ 5
Feedback ......................................................................................................................... 5
Penetration Testing Workflow............................................................................................ 6
Checklist ............................................................................................................................. 8AppDOS.......................................................................................................................... 8
AccessControl ................................................................................................................. 9Authentication............................................................................................................... 10
Authentication. User ..................................................................................................... 10
Authentication. SessionManagement............................................................................ 11
Configuration. Management ......................................................................................... 12
Configuration. Management Infrastructure .................................................................. 13
Configuration. Management. Application .................................................................... 13
Error Handling .............................................................................................................. 13
DataProtection............................................................................................................... 14
DataProtection. Transport ............................................................................................. 14
InputValidation ............................................................................................................. 15
InputValidation.SQL..................................................................................................... 15
InputValidation.OS ....................................................................................................... 15
InputValidation.LDAP.................................................................................................. 15
InputValidation.XSS..................................................................................................... 15
BufferOverflow............................................................................................................. 16
Appendix A - The OASIS WAS Vulnerability Types...................................................... 17

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.

Introduction
Penetration testing will never be an exact science where a complete list of all possible
issues that should be tested can de defined. Indeed penetration is only an appropriatetechnique to test the security of web applications under certain circumstances. For
information about what these circumstances are, and to learn how to build a testing
framework and which testing techniques you should consider, we recommend reading the
OWASP Testing Framework Part One (http://www.owasp.org). Risk Management Guidefor Information Technology Systems, NIST 800-30 1describes vulnerabilities inoperational, technical and management categories. Penetration testing alone does notreally help identify operational and management vulnerabilities.
Many OWASP followers (especially financial services companies) however have asked
OWASP to develop a checklist that they can use when they do undertake penetration
testing to promote consistency among both internal testing teams and external vendors.
As such this list has been developed to be used in several ways including;•••

RFP Template
Benchmarks
Testing Checklist

This checklist provides issues that should be tested. It does not prescribe techniques thatshould be used.

Using this Checklist as an RFP Template
Some people expressed the need for a checklist from which they can request services
from vendors and consulting companies to ensure consistency, and from which they cancompare approaches and results on a level playing field. As such, this list can form thebasis of a Request for Proposal for services to a vendor. In effect, you are asking thevendor to perform all of the services listed.
NB: If you or your company develops an RFP Template from this checklist, please shareit with OWASP and the community. Send it to testing@owasp.org with the Subject[Testing Checklist RFP Template].

Using this Checklist as a Benchmark
Some people expressed the need for a checklist from which they can base their internal
testing on and from which they can then use the result to develop metrics. Using the same
checklist allows people to compare different applications and even different sources ofdevelopment as “apples to apples”. The OASIS WAS project (http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=was) will provide a set of vulnerability
types that can be used as a classification scheme and therefore have been adopted into1

http://csrc.nist.gov/publications/nistpubs/index.html#sp800-30 – The revised version can be found at
http://csrc.nist.gov/publications/drafts/SP800-30-RevA-draft.pdf
The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.

this checklist to help people sort data easier. For more information see the section on
OASIS WAS below.

Using this Checklist as a Checklist
Of course many people will want to use this checklist as just that; a checklist or crib
sheet. As such the list is written as a set of issues that need to be tested. It does notprescribe techniques that should be used (although examples are provided).

About the OWASP Testing Project (Parts One and Two)
The OWASP is currently working on a comprehensive Testing Framework. By the time
you read this document Part One will be close to release and Part Two will be underway.
Part One of the Testing Framework describes the Why, What, Where and When of testing
the security of web applications and Part Two goes into technical details about how tolook for specific issues using source code inspection and a penetration testing (forexample exactly how to find SQL Injection flaws in code and through penetration
testing). This check list is likely to become an Appendix to Part Two of the OWASPTesting framework along with similar check lists for source code review.

The OASIS WAS Standard
The issues identified in this check list are not ordered in a specific manner of importanceor criticality. Several members of the OWASP Team are working on an XML standard todevelop a way to consistently describe web application security issues at OASIS. The
mission of OASIS is to drive the development, convergence, and adoption of structured
information standards in the areas of e-business, web services, etc. For more information
about OASIS you should view the website http://www.oasis-open.org.
We believe OASIS WAS will become a very important standard which will allow people
to develop vulnerability management / risk management systems and processes on top of
the data. As this work is taking place at an official standards body its independence ofvendor bias or technology and the fact that its longevity can be guaranteed, makes itsuitable to base your work on. Part of the OASIS WAS standard will be a set ofvulnerability types. These are standard vulnerability issues that will have standard textual
definitions that allow people to build consistent classification schemes / thesauruses.
Using these vulnerability types people can create useful views into their vulnerability
data.
The OASIS WAS XL standard is due to be published in August. The WAS Vulnerability
Types are due to be published as a separate document in draft at the end of April. As such
this list “may” change when the standard is ratified although this is unlikely.
As we believe the WAS vulnerability types will become an integral part of application
vulnerability management in the future, it will be tightly coupled to all OWASP work
such as this checklist and the OWASP Testing Framework.
The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.

About OWASPOWASP is a volunteer organization that is dedicated to developing knowledge based
documentation and reference implementations and software that can be used by systemarchitects, developers and security professionals. Our work promotes and helps
consumers build more secure web applications.
For more information about OWASP see the web site http://www.owasp.org

Feedback
To provide feedback on this checklist please send an email to testing@owasp.org with asubject [Pen Testing Checklist Feedback]. We welcome all comments and suggestions. If
your suggestion is for a new issue, please detail the issue as you would like to see it in the
checklist. If your suggestion is a correction or improvement, please send your comments
and a suggested completed text for the change. As a volunteer group, the easier yourchanges are to make, the faster they can be incorporated into our revisions.

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.

Penetration Testing Workflow
Clearly, by promoting a checklist we are promoting methodical and repeatable testing.
Whilst it is beyond scope of this checklist to prescribe a penetration testing methodology(this will be covered in OWASP Testing Part Two), we have included a model testing
workflow below. Below is a flow diagram that the tester may find useful when using thetesting techniques described in this document. It is important to note that an infrastructurelevel penetration test should be performed prior to performing the application test. In
some cases, the server operating system can be exploited and give the tester further
leverage in exploiting the web application.
The flow diagram below is based around several steps:-

The penetration test starts by gathering all possible information available
regarding the infrastructure and applications involved. This stage is paramount as
without a solid understanding of the underlying technology involved, sections
may be missed during the testing phase-

The test should follow all the different phases described below-

Testers should attempt to exploit all discovered vulnerabilities. Even if the
exploitation fails, the tester will have a better understanding of the vulnerabilityrisk-

Any information returned by checking for vulnerabilities, for example,
programming errors, source code retrieval or other internal information
disclosure, should be used to re-assess the overall understanding of the applicationand how it performs-

If at any point during the testing a vulnerability is detected, which may lead to thesuccessful compromise of the target or disclose business-critical information, therelevant contact for the company should be contacted immediately and madeaware of the situation and risks involved.

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.

Checklist
Category

Ref Number
OWASP-AD-001

Name
Application Flooding

OWASP-AD-002

Application Lockout

AppDOS

Objective
Ensure that the application
functions correctly when presented
with large volumes of requests,
transactions and / or network
traffic.
Ensure that the application does
not allow an attacker to reset or
lockout user’s accounts.

Notes
Use various fuzzing
tools to perform thistest (e.g. SPIKE)The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.

Category
AccessControl

Ref Number
OWASP-AC001

Name
Parameter Analysis

Objective
Ensure that the application enforces
its access control model by ensuringthat any parameters available to an
attacker would not afford additional
service.

OWASP-AC002

Authorization

OWASP-AC003

Authorization
Parameter
Manipulation

OWASP-AC004

Authorized
pages/functions

OWASP-AC005

Application Workflow

Ensure that resources that requireauthorization perform adequate
authorization checks before being
sent to a user.
Ensure that once valid user has
logged in it is not possible to change
the session ID’s parameter to reflect
another user accountCheck to see if its possible to accesspages or functions which requirelogon but can be bypassed
Ensure that where the application
requires the user to perform actions
in a specific sequence, the sequenceis enforced.

Notes
Typically thisincludesmanipulation of form
fields, URL query
strings, client-side
script values andcookies.

i.e. accountnumber,policynumber,usernr
etc.

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.

Category
Authentication

Authentication.
User

Ref Number
OWASPAUTHN-001

Name
Objective
Authentication endpoint
Ensure that users are only asked torequest should be HTTPS submit authentication credentials
on pages that are served with SSL.

OWASPAUTHN-002

Authentication bypass

Ensure that the authentication
process can not be bypassed.

OWASPAUTHN-003

Credentials transport
over an encryptedchannelDefault Accounts

Ensure that usernames andpasswords are sent over an
encrypted channel.
Check for default account names
and passwords in use
Ensure that the username is not
public (or “wallet”) informationsuch as email or SSN.
Ensure that the password
complexity makes guessing
passwords difficult.
Ensure that user must respond to asecret answer / secret question orother predetermined information
before passwords can be reset.

OWASPAUTHN-004
OWASPAUTHN-005

UsernameOWASPAUTHN-006

Password Quality

OWASPAUTHN-007

Password Reset

Notes
This ensures that theuser knows who isasking for his / hercredentials as well as
where they are being
sent.
Typically thishappens inconjunction withflaws like SQL
Injection.
Typically this should
be SSL.

Ensure thatpasswords are notsent to users in email.

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.

Category

Authentication.
SessionManagem
ent

Ref Number
OWASPAUTHN-008

Name
Password Lockout

OWASPAUTHN-009

Password Structure

OWASPAUTHN-010
OWASPAUTHSM001

Blank Passwords

OWASPAUTHSM002

Session Timeout

OWASPAUTHSM003

Session ReuseOWASPAUTHSM004
OWASPAUTHSM005

Session Deletion

Session Token Length

Session Token Format

Objective
Ensure that the users account islocked out for a period of time
when the incorrect password isentered more that a specificnumber of times (usually 5).
Ensure that special meta characters
cannot be used within the
password
Ensure that passwords are notblank
Ensure that the session token is ofadequate length to provide
protection from guessing during anauthenticated session.
Ensure that the session tokens are
only valid for a predetermined
period after the last request by theuser.
Ensure that session tokens arechanged when the user moves
from an SSL protected resource toa non-SSL protected resource.
Ensure that the session token isinvalidated when the user logs out.

Notes

Can be useful when
performing SQL
injection

Ensure that the session token is
non-persistent and is never written
to the browsers history or cache.

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.

CategoryConfiguration.
Management

Ref Number
OWASP-CM001

Name
HTTP Methods

OWASP-CM002

Virtually Hosted Sites

OWASP-CM003

Known Vulnerabilities /Security Patches

OWASP-CM004

Back-up FilesOWASP-CM004

Web Server
Configuration

OWASP-CM005

Web Server Components

OWASP-CM006

Common Paths

Objective
Ensure that the web server does
not support the ability tomanipulate resources from theInternet (e.g. PUT and DELETE)
Try and determine if site isvirtually hosted.

Notes

If there are furthersites, they could bevulnerable and leadto the compromise of
the base server

Ensure that known vulnerabilities
which vendors have patched are
not present.
Ensure that no backup files ofsource code are accessible on the
publicly accessible part of theapplication.
Ensure that common configuration
issues such as directory listingsand sample files have beenaddressed
Ensure that web server
components like Front Page Server
Extensions or Apache modules do
not introduce any security
vulnerabilities
Check for existence of common/backup & /admin
directories within the application
may containroot
information

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.

CategoryConfiguration.
Management
Infrastructure

Configuration.
Management.
Application

Category

Ref Number
OWASP-CM007

Name
Language/Application
defaults

OWASP-CM008

Infrastructure Admin
Interfaces

OWASP-CM009

Application Admin
Interfaces

Ref Number
OWASP-EH-001

Name
Application Error
MessagesOWASP-EH-002

User Error Messages

Error
Handling

Objective
I.e. J2EE environmental quirks e.g
Availability of snoop.jsp /*Spy.jsp
and loaded modules
Ensure that administrativeinterfaces to infrastructure such as
web servers and application
servers are not accessible to theInternet.
Ensure that administrativeinterfaces to the applications are
not accessible to the Internet.

Notes

Objective
Ensure that the application does
not present application error
messages to an attacker that could
be used in an attack.

Notes
This typically occurs
when applications
return verbose error
messages such as
stack traces or
database errors.
Ensure that the application does
This typically occurs
not present user error messages to when applications
an attacker that could be used in an return error messages
attack.
such as “User does
not exist” or “User
Correct, Password
Incorrect”

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.

Category
DataProtection

DataProtection.
Transport

Ref Number
OWASP-DP001

Name
Sensitive Data in HTML

Objective
Ensure that there is no sensitive
data in the HTML (cached in thebrowser history) that could lead anattacker to mount a focused attack.

OWASP-DP002

Data StorageOWASP-DP003

SSL Version

OWASP-DP004

SSL Key Exchange
Methods

OWASP-DP005

SSL Algorithms

Ensure where required, data is
protected to protect its
confidentiality and integrity.
Ensure that SSL versions
supported do not havecryptographic weaknesses.
Ensure that the web server does
not allow anonymous key
exchange methods.
Ensure that weak algorithms are
not available.

OWASP-DP006

SSL Key Lengths

Ensure the web site uses anappropriate length key.

OWASP-DP007

Digital Certificate
Validity

Ensure the application uses valid
digital certificates.

Notes
This typically occurs
when developers
leave information in
html comment or theapplication renders
names and addresses
in HTML.

Typically this means
supporting SSL 3 andTLS 1.0 only.
Typically ADH
Anonymous DiffieHellman.
Typically algorithms
such as RC2 andDES.
Most web sites
should enforce 128
bit encryption.
Ensure that the digital
certificate is valid,that is to say its
signature, host, dateetc are all valid.

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.

Category
InputValidation

InputValidation.
SQL
InputValidation.
OS

InputValidation.
LDAP
InputValidation.
XSS

Ref Number
OWASP-IV001

Name
Script Injection

OWASP-IV002

SQL Injection

OWASP-IV003

OS Command Injection

OWASP-IV004

LDAP Injection

OWASP-IV005

Cross Site Scripting

Objective
Ensure that any part of theapplication that allows input does
not process scripts as part of the
input.
Ensure the application will notprocess SQL commands from theuser.
Ensure the applications will notprocess operating systemcommands from the user.

Notes
Classic case of Cross
Site Scripting but
includes otherscripting as well.

This typically
includes issues suchas path traversal,
spawning commandshells and OS
functions.

Ensure the application will notprocess LDAP commands form
the user.
Ensure that the application will notstore or reflect malicious script
code.

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.

Category
BufferOverflow

Ref Number
OWASP-BO001

Name
Overflows

Objective
Ensure that the application is not
susceptible to any buffer
overflows.

OWASP-BO002
OWASP-BO003
OWASP-BO004

Heap Overflows

Ensure that the application is not
susceptible to any heap overflows.
Ensure that the application is not
susceptible to any stack overflows.
Ensure that the application is not
susceptible to any format string
overflows.

Stack Overflows
Format Strings

Notes
Fuzzing tools help
with testing allcomponents of an
application for thisissue.

The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.

Appendix A - The OASIS WAS Vulnerability Types
AppDOS
Flaws which may would allow an attacker to completely or partially prevent users fromusing an application properly.
AppDOS.Flood
Used for application denial of service problems that involve saturating a limited resourceshared by all users of the application, such as disk space, CPU, network bandwidth,
database connections, or memory.
AppDOS.Lockout
Used for application denial of service problems that involve using up a resource or limit
allocated to users, such as failed logon attempts, messages, or transactions.
AccessControl
Problems which may allow users to access assets or functions they are not authorized for.
Frequently, there is no access control mechanism where there should be. A proper access
control mechanism should enforce the principles of a reference monitor: tamperproof,
and analyzable.
Authentication
Used for problems related to determining the identity of individuals or entities andauthenticating that identity.
Authentication.User
Used for issues related to identification and authentication of people who are intended touse an application. Problems with usernames, passwords, tokens, smartcards, biometrics,
and other credentials are examples.
Authentication.UserManagement
Used for problems related to managing a set of users, especially the security relevant
information such as roles, privileges, authorizations, groups, social security numbers,
credit card numbers, and other sensitive information. Also problems with creating newusers, registration, granting rights, and terminating access.
Authentication.Entity
Used for problems with authenticating automated systems, such as web services,
databases, directories, and others. Examples include secure credential storage, securingtransport, changing credentials, and terminating access.
Authentication.SessionManagement
Used for problems with issuing, using, protecting, changing, and terminating session
identifiers of all kinds. Session identifiers stand in the place of authentication credentials
yet are frequently not protected as carefully.
BufferOverflow
Flaws which may allow an attacker to use format strings to overwrite locations inmemory, allowing data to be changed, program control to be altered, or the program tocrash.
BufferOverflow.Heap
Flaws which may allow an attacker to overflow memory that is dynamically allocated by
the application.
The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.

BufferOverflow.Stack
Flaws which may allow an attacker to write data into the stack, causing the program tocrash or transfer control.
BufferOverflow.Format
Flaws which may allow an attacker to use format strings to overwrite locations inmemory, allowing data to be changed, program control to be altered, or the program tocrash.
Concurrency
Used for errors in multithreaded environments that allows data to be shared or corrupted.
Examples include variables that are shared between threads and cause time-of-checktime-of-use (TOCTOU) problems, broken singleton patterns, and poor cache design.
ConfigurationManagement
Used to describe problems in the configuration of an application or application
environment.
ConfigurationManagement.Administration
Used for problems in the application's mechanisms that enable remote administration,such as user management, credential management, database management, and otherconfiguration options.
ConfigurationManagement.Application
Used to describe problems in the application's configuration, such as mis-configured
security mechanisms, default programs, unused code, and unnecessarily enabled features.
ConfigurationManagement.Infrastrure
Used for problems with the configuration of the application's infrastructure, such as the
web and application servers, filters, and external security mechanisms.
Cryptography
Used for problems related to encryption, decryption, signing, and verification.
Cryptography.Algorithm
Used for cryptographic algorithm selection, implementation, and analysis problems.
Cryptography.KeyManagement
Used for issues with certificate storage, tokens, revocation, certificates, key stores,
issuing keys, and other key issues
DataProtection
Used for issues related to inappropriate disclosure of data.
DataProtection.Storage
Used for problems storing data securely, including storage of credentials, keys, and othersensitive information. Mistakes related to cryptographic mechanisms include poorsources of randomness, bad choice of algorithm, and poor implementation.
DataProtection.Transport
Used for problems related to secure transfer of information. Frequently, this will refer toproblems with SSL or TLS configuration, but could include other protocols with security
features.
ErrorHandling
Used for problems in handling errors, including printing stack traces to the screen, failopen security mechanisms, allowing errors to affect the operation of the entire
application, and revealing too much information about a failure.
The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.

InputValidation
Used for issues related to failure to validate un-trusted input before it is relied on by anapplication.
InputValidation.User
Used for input validation problems where the input comes from a human user, such as
HTTP request parameters, command line input, or input events from an application's
GUI.
InputValidation.Network
Used for input validation problems where the input comes from a network protocol, suchas HTTP headers, sequence numbers, or other protocol fields.
InputValidation.File
Used for input validation problems where the input comes from a file, such as aproperties file, batch data file, flat-file databases, or other file based data.
Injection
Problems which may allow an attacker to bury commands into data and have theminterpreted by some system that the data reaches.
Injection.SQL
Flaws which may allow an attacker to inject special characters and commands into a SQL
database and modify the intended query. The attack might attempt to change the meaningof the query, or might attempt to chain additional commands.
Injection.HTML
Flaws which may allow an attacker to inject HTML into an application and modify theappearance of HTML generated by that application. For example, an attacker might injectan unwanted IMG tag into a guest book, and offend other users.
Injection.OSCommand
Flaws which may allow an attacker to inject special characters and commands into theoperating system command shell and modify the intended command. The attack might
attempt to modify how a program is invoked, or might attempt to chain additionalcommands.
Injection.LDAP
Flaws which may allow an attacker to inject special characters and search terms into an
LDAP server and modify the intended query.
Injection.XSS
Flaws which may allow an attacker to send and execute malicious scripts through a web
application. Stored XSS attacks store the script in the web application. Reflected XSS
attacks are bounced off a web application in real time and require a user to be tricked into
sending the request containing the attack.
Monitoring
Used for issues related to monitoring the security posture of a web application.
Monitoring.Logging
Used for issues concerning the proper logging of events, including what should be
logged, how it should be logged, how logs should be reviewed, and other issues related toaccountability.
Monitoring.Detection
Used for issues related to the detection of attacks on an application, how attacks should
be handled, what information should be gathered, and who should be notified.
The OWASP Web Application Penetration Check List
This document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.