Transcription
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 [email protected] 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 [email protected] 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 the GNU documentation license and is Copyrighted to the OWASP Foundation. You should read and understand that license and copyright conditions.
CategoryDataProtectionDataProtection.TransportRef NumberOWASP-DP001NameSensitive Data in HTMLObjectiveEnsure that there is no sensitivedata in the HTML (cached in thebrowser history) that could lead anattacker to mount a focused attack.OWASP-DP002Data StorageOWASP-DP003SSL VersionOWASP-DP004SSL Key ExchangeMethodsOWASP-DP005SSL AlgorithmsEnsure where required, data isprotected to protect itsconfidentiality and integrity.Ensure that SSL versionssupported do not havecryptographic weaknesses.Ensure that the web server doesnot allow anonymous keyexchange methods.Ensure that weak algorithms arenot available.OWASP-DP006SSL Key LengthsEnsure the web site uses anappropriate length key.OWASP-DP007Digital CertificateValidityEnsure the application uses validdigital certificates.NotesThis typically occurswhen developersleave information inhtml comment or theapplication rendersnames and addressesin HTML.Typically this meanssupporting SSL 3 andTLS 1.0 only.Typically ADHAnonymous DiffieHellman.Typically algorithmssuch as RC2 andDES.Most web sitesshould enforce 128bit encryption.Ensure that the digitalcertificate is valid,that is to say itssignature, host, dateetc are all valid.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.
ef NumberOWASP-IV001NameScript InjectionOWASP-IV002SQL InjectionOWASP-IV003OS Command InjectionOWASP-IV004LDAP InjectionOWASP-IV005Cross Site ScriptingObjectiveEnsure that any part of theapplication that allows input doesnot process scripts as part of theinput.Ensure the application will notprocess SQL commands from theuser.Ensure the applications will notprocess operating systemcommands from the user.NotesClassic case of CrossSite Scripting butincludes otherscripting as well.This typicallyincludes issues suchas path traversal,spawning commandshells and OSfunctions.Ensure the application will notprocess LDAP commands formthe user.Ensure that the application will notstore or reflect malicious scriptcode.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.
CategoryBufferOverflowRef NumberOWASP-BO001NameOverflowsObjectiveEnsure that the application is notsusceptible to any eap OverflowsEnsure that the application is notsusceptible to any heap overflows.Ensure that the application is notsusceptible to any stack overflows.Ensure that the application is notsusceptible to any format stringoverflows.Stack OverflowsFormat StringsNotesFuzzing tools helpwith testing allcomponents of anapplication for thisissue.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.
Appendix A - The OASIS WAS Vulnerability TypesAppDOSFlaws which may would allow an attacker to completely or partially prevent users fromusing an application properly.AppDOS.FloodUsed 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.LockoutUsed for application denial of service problems that involve using up a resource or limitallocated to users, such as failed logon attempts, messages, or transactions.AccessControlProblems 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 accesscontrol mechanism should enforce the principles of a reference monitor: tamperproof,and analyzable.AuthenticationUsed for problems related to determining the identity of individuals or entities andauthenticating that identity.Authentication.UserUsed 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.UserManagementUsed for problems related to managing a set of users, especially the security relevantinformation 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.EntityUsed 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.SessionManagementUsed for problems with issuing, using, protecting, changing, and terminating sessionidentifiers of all kinds. Session identifiers stand in the place of authentication credentialsyet are frequently not protected as carefully.BufferOverflowFlaws 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.HeapFlaws which may allow an attacker to overflow memory that is dynamically allocated bythe application.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.
BufferOverflow.StackFlaws which may allow an attacker to write data into the stack, causing the program tocrash or transfer control.BufferOverflow.FormatFlaws 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.ConcurrencyUsed 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.ConfigurationManagementUsed to describe problems in the configuration of an application or inistrationUsed for problems in the application's mechanisms that enable remote administration,such as user management, credential management, database management, and otherconfiguration options.ConfigurationManagement.ApplicationUsed to describe problems in the application's configuration, such as mis-configuredsecurity mechanisms, default programs, unused code, and unnecessarily enabled features.ConfigurationManagement.InfrastrureUsed for problems with the configuration of the application's infrastructure, such as theweb and application servers, filters, and external security mechanisms.CryptographyUsed for problems related to encryption, decryption, signing, and verification.Cryptography.AlgorithmUsed for cryptographic algorithm selection, implementation, and analysis problems.Cryptography.KeyManagementUsed for issues with certificate storage, tokens, revocation, certificates, key stores,issuing keys, and other key issuesDataProtectionUsed for issues related to inappropriate disclosure of data.DataProtection.StorageUsed 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.TransportUsed for problems related to secure transfer of information. Frequently, this will refer toproblems with SSL or TLS configuration, but could include other protocols with securityfeatures.ErrorHandlingUsed for problems in handling errors, including printing stack traces to the screen, failopen security mechanisms, allowing errors to affect the operation of the entireapplication, and revealing too much information about a failure.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.
InputValidationUsed for issues related to failure to validate un-trusted input before it is relied on by anapplication.InputValidation.UserUsed for input validation problems where the input comes from a human user, such asHTTP request parameters, command line input, or input events from an application'sGUI.InputValidation.NetworkUsed for input validation problems where the input comes from a network protocol, suchas HTTP headers, sequence numbers, or other protocol fields.InputValidation.FileUsed 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.InjectionProblems which may allow an attacker to bury commands into data and have theminterpreted by some system that the data reaches.Injection.SQLFlaws which may allow an attacker to inject special characters and commands into a SQLdatabase and modify the intended query. The attack might attempt to change the meaningof the query, or might attempt to chain additional commands.Injection.HTMLFlaws 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.OSCommandFlaws which may allow an attacker to inject special characters and commands into theope
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 writt
