OWASP Web Application Penetration Checklist
OWASP Web Application Penetration ChecklistVersion 1.1The OWASP Web Application Penetration Check ListThis 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. 3Using this Checklist as an RFP Template. 3Using this Checklist as a Benchmark. 3Using this Checklist as a Checklist. 4About the OWASP Testing Project (Parts One and Two). 4The OASIS WAS Standard. 4About OWASP. 5Feedback . 5Penetration Testing Workflow. 6Checklist . 8AppDOS. 8AccessControl . 9Authentication. 10Authentication. User . 10Authentication. SessionManagement. 11Configuration. Management . 12Configuration. Management Infrastructure . 13Configuration. Management. Application . 13Error Handling . 13DataProtection. 14DataProtection. Transport . 14InputValidation . 15InputValidation.SQL. 15InputValidation.OS . 15InputValidation.LDAP. 15InputValidation.XSS. 15BufferOverflow. 16Appendix A - The OASIS WAS Vulnerability Types. 17The OWASP Web Application Penetration Check ListThis document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.
IntroductionPenetration testing will never be an exact science where a complete list of all possibleissues that should be tested can de defined. Indeed penetration is only an appropriatetechnique to test the security of web applications under certain circumstances. Forinformation about what these circumstances are, and to learn how to build a testingframework and which testing techniques you should consider, we recommend reading theOWASP 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 askedOWASP to develop a checklist that they can use when they do undertake penetrationtesting 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 TemplateBenchmarksTesting ChecklistThis checklist provides issues that should be tested. It does not prescribe techniques thatshould be used.Using this Checklist as an RFP TemplateSome people expressed the need for a checklist from which they can request servicesfrom 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 BenchmarkSome people expressed the need for a checklist from which they can base their internaltesting on and from which they can then use the result to develop metrics. Using the samechecklist 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 vulnerabilitytypes that can be used as a classification scheme and therefore have been adopted dex.html#sp800-30 – The revised version can be found 0-RevA-draft.pdfThe OWASP Web Application Penetration Check ListThis 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 onOASIS WAS below.Using this Checklist as a ChecklistOf course many people will want to use this checklist as just that; a checklist or cribsheet. 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 timeyou 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 testingthe 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 penetrationtesting). 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 StandardThe 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. Themission of OASIS is to drive the development, convergence, and adoption of structuredinformation standards in the areas of e-business, web services, etc. For more informationabout OASIS you should view the website http://www.oasis-open.org.We believe OASIS WAS will become a very important standard which will allow peopleto develop vulnerability management / risk management systems and processes on top ofthe 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 textualdefinitions that allow people to build consistent classification schemes / thesauruses.Using these vulnerability types people can create useful views into their vulnerabilitydata.The OASIS WAS XL standard is due to be published in August. The WAS VulnerabilityTypes are due to be published as a separate document in draft at the end of April. As suchthis 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 applicationvulnerability management in the future, it will be tightly coupled to all OWASP worksuch as this checklist and the OWASP Testing Framework.The OWASP Web Application Penetration Check ListThis 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 baseddocumentation and reference implementations and software that can be used by systemarchitects, developers and security professionals. Our work promotes and helpsconsumers build more secure web applications.For more information about OWASP see the web site http://www.owasp.orgFeedbackTo 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. Ifyour suggestion is for a new issue, please detail the issue as you would like to see it in thechecklist. If your suggestion is a correction or improvement, please send your commentsand 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 ListThis 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 WorkflowClearly, 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 testingworkflow 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. Insome cases, the server operating system can be exploited and give the tester furtherleverage in exploiting the web application.The flow diagram below is based around several steps:-The penetration test starts by gathering all possible information availableregarding the infrastructure and applications involved. This stage is paramount aswithout a solid understanding of the underlying technology involved, sectionsmay 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 theexploitation 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 informationdisclosure, 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 ListThis 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 ListThis document is released under the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read andunderstand that license and copyright conditions.
ChecklistCategoryRef NumberOWASP-AD-001NameApplication FloodingOWASP-AD-002Application LockoutAppDOSObjectiveEnsure that the applicationfunctions correctly when presentedwith large volumes of requests,transactions and / or networktraffic.Ensure that the application doesnot allow an attacker to reset orlockout user’s accounts.NotesUse various fuzzingtools to perform thistest (e.g. SPIKE)The OWASP Web Application Penetration Check ListThis 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.
CategoryAccessControlRef NumberOWASP-AC001NameParameter AnalysisObjectiveEnsure that the application enforcesits access control model by ensuringthat any parameters available to anattacker would not afford thorizedpages/functionsOWASP-AC005Application WorkflowEnsure that resources that requireauthorization perform adequateauthorization checks before beingsent to a user.Ensure that once valid user haslogged in it is not possible to changethe session ID’s parameter to reflectanother user accountCheck to see if its possible to accesspages or functions which requirelogon but can be bypassedEnsure that where the applicationrequires the user to perform actionsin a specific sequence, the sequenceis enforced.NotesTypically thisincludesmanipulation of formfields, URL querystrings, client-sidescript values andcookies.i.e. accountnumber,policynumber,usernretc.The OWASP Web Application Penetration Check ListThis 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.
CategoryAuthenticationAuthentication.UserRef NumberOWASPAUTHN-001NameObjectiveAuthentication endpointEnsure that users are only asked torequest should be HTTPS submit authentication credentialson pages that are served with SSL.OWASPAUTHN-002Authentication bypassEnsure that the authenticationprocess can not be bypassed.OWASPAUTHN-003Credentials transportover an encryptedchannelDefault AccountsEnsure that usernames andpasswords are sent over anencrypted channel.Check for default account namesand passwords in useEnsure that the username is notpublic (or “wallet”) informationsuch as email or SSN.Ensure that the passwordcomplexity makes guessingpasswords difficult.Ensure that user must respond to asecret answer / secret question orother predetermined informationbefore passwords can be HN-006Password QualityOWASPAUTHN-007Password ResetNotesThis ensures that theuser knows who isasking for his / hercredentials as well aswhere they are beingsent.Typically thishappens inconjunction withflaws like SQLInjection.Typically this shouldbe SSL.Ensure thatpasswords are notsent to users in email.The OWASP Web Application Penetration Check ListThis 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.
CategoryAuthentication.SessionManagementRef NumberOWASPAUTHN-008NamePassword LockoutOWASPAUTHN-009Password StructureOWASPAUTHN-010OWASPAUTHSM001Blank PasswordsOWASPAUTHSM002Session TimeoutOWASPAUTHSM003Session ReuseOWASPAUTHSM004OWASPAUTHSM005Session DeletionSession Token LengthSession Token FormatObjectiveEnsure that the users account islocked out for a period of timewhen the incorrect password isentered more that a specificnumber of times (usually 5).Ensure that special meta characterscannot be used within thepasswordEnsure that passwords are notblankEnsure that the session token is ofadequate length to provideprotection from guessing during anauthenticated session.Ensure that the session tokens areonly valid for a predeterminedperiod after the last request by theuser.Ensure that session tokens arechanged when the user movesfrom an SSL protected resource toa non-SSL protected resource.Ensure that the session token isinvalidated when the user logs out.NotesCan be useful whenperforming SQLinjectionEnsure that the session token isnon-persistent and is never writtento the browsers history or cache.The OWASP Web Application Penetration Check ListThis 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.ManagementRef NumberOWASP-CM001NameHTTP MethodsOWASP-CM002Virtually Hosted SitesOWASP-CM003Known Vulnerabilities /Security PatchesOWASP-CM004Back-up FilesOWASP-CM004Web ServerConfigurationOWASP-CM005Web Server ComponentsOWASP-CM006Common PathsObjectiveEnsure that the web server doesnot support the ability tomanipulate resources from theInternet (e.g. PUT and DELETE)Try and determine if site isvirtually hosted.NotesIf there are furthersites, they could bevulnerable and leadto the compromise ofthe base serverEnsure that known vulnerabilitieswhich vendors have patched arenot present.Ensure that no backup files ofsource code are accessible on thepublicly accessible part of theapplication.Ensure that common configurationissues such as directory listingsand sample files have beenaddressedEnsure that web servercomponents like Front Page ServerExtensions or Apache modules donot introduce any securityvulnerabilitiesCheck for existence of common/backup & /admindirectories within the applicationmay containrootinformationThe OWASP Web Application Penetration Check ListThis 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.
iguration.Management.ApplicationCategoryRef WASP-CM008Infrastructure AdminInterfacesOWASP-CM009Application AdminInterfacesRef NumberOWASP-EH-001NameApplication ErrorMessagesOWASP-EH-002User Error MessagesErrorHandlingObjectiveI.e. J2EE environmental quirks e.gAvailability of snoop.jsp /*Spy.jspand loaded modulesEnsure that administrativeinterfaces to infrastructure such asweb servers and applicationservers are not accessible to theInternet.Ensure that administrativeinterfaces to the applications arenot accessible to the Internet.NotesObjectiveEnsure that the application doesnot present application errormessages to an attacker that couldbe used in an attack.NotesThis typically occurswhen applicationsreturn verbose errormessages such asstack traces ordatabase errors.Ensure that the application doesThis typically occursnot present user error messages to when applicationsan attacker that could be used in an return error messagesattack.such as “User doesnot exist” or “UserCorrect, PasswordIncorrect”The OWASP Web Application Penetration Check ListThis document is released under
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 to look for specific issues using source code inspection and a penetration testing (for example exactly how to find SQL Injection flaws in code and through penetration testing).
OWASP Code review guide, V1.1 The Ruby on Rails Security Guide v2 OWASP UI Component Verification Project (a.k.a. OWASP JSP Testing Tool) Internationalization Guidelines and OWASP-Spanish Project OWASP Application Security Desk Reference (ASDR) OWASP .NET Project Leader OWASP Education Project
Assessment, Penetration Testing, Vulnerability Assessment, and Which Option is Ideal to Practice? Types of Penetration Testing: Types of Pen Testing, Black Box Penetration Testing. White Box Penetration Testing, Grey Box Penetration Testing, Areas of Penetration Testing. Penetration Testing Tools, Limitations of Penetration Testing, Conclusion.
Application penetration test includes all the items in the OWASP Top 10 and more. The penetration tester remotely tries to compromise the OWASP Top 10 flaws. The flaws listed by OWASP in its most recent Top 10 and the status of the application against those are depicted in the table below.
Threat Prevention Coverage – OWASP Top 10 Analysis of Check Point Coverage for OWASP Top 10 Website Vulnerability Classes The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. OWASP mission is to make software security visible, so that individuals and
OWASP effort. This shows how much passion the community has for the OWASP Top 10, and thus how critical it is for OWASP to get the Top 10 right for the majority of use cases. Although the original goal of the OWASP Top 10 project was simply to raise awareness amongst developers and managers, it has become . the. de facto application security .
The OWASP Top 10 Proactive Controls is similar to the OWASP Top 10 but is focused on defensive techniques and controls as opposed to risks. Each technique or control in this document will . OWASP Mobile Application Security Verification Standard (MASVS) OWASP Top Ten .
1 Bo Berlas Included the OWASP Web Application Penetration Checklist and the OWASP Testing Project documents as embedded objects into Appendix C – GSA Risk Assessment Security Requirements. To provide a usable checklist for testing the OWASP Top Ten Vulnerabilities. 14 Revision 2 – February 13, 2007 1 Bo Berlas Various updates to reflect
Open Web Application Security Project (OWASP) National Institute of Standards and Technology (NIST) Penetration Testing Execution Standard (PTES) What is PTES? PTES, penetration testing execution standard, as the name implies is an assessment methodology for penetration testing. It covers everything related to a penetration test.
