Test Standards

The primary aim of the OWASP Application Security Verification Standard (ASVS) Project is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:

Use as a metric– Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,

Use as guidance – Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and

Use during procurement – Provide a basis for specifying application security verification requirements in contracts.

V1: Authentication Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

AUTHENTICATION

LEVELS

VERIFICATION REQUIREMENT

1

2

3

V1.1

Verify all pages and resources require authentication except those specifically intended to be public (Principle of complete mediation).

V1.2

Verify all password fields do not echo the user’s password when it is entered, and that password fields (or the forms that contain them) have autocomplete disabled.

Verify there are no default passwords in use for the application framework or any components used by the application (such as “admin/password”).

V1.8

Verify that a resource governor is in place to protect against vertical (a single account tested against all possible passwords) and horizontal brute forcing (all accounts tested with the same password e.g. “Password1”). A correct credential entry should incur no delay. For example, if an attacker tries to brute force all accounts with the single password “Password1”, each incorrect attempt incurs a linear back off (say 5, 25, 125, 625 seconds) with a soft lock of say 15 minutes for that IP address before being allowed to proceed. A similar control should also be in place to protect each account, with a linear back off configurable with a soft lock against the user account of say 15 minutes before being allowed to try again, regardless of source IP address. Both these governor mechanisms should be active simultaneously to protect against diagonal and distributed attacks.

V1.9

Verify all authentication controls are enforced on the server side.

V1.10

Verify password entry fields allow or encourage the use of passphrases, and do not prevent long passphrases or highly complex passwords being entered, and provide a sufficient minimum strength to protect against the use of commonly chosen passwords.

V1.11

Verify all account management functions (such as registration, update profile, forgot username, forgot password, disabled / lost token, help desk or IVR) that might regain access to the account are at least as resistant to attack as the primary authentication mechanism.

V1.12

Verify users can safely change their credentials using a mechanism that is at least as resistant to attack as the primary authentication mechanism.

V1.13

Verify authentication credentials can expire after an administratively configurable period of time.

V1.14

Verify that all authentication decisions are logged, including linear back offs and soft-locks.

V1.15

Verify that account passwords are salted using a salt that is unique to that account (e.g., internal user ID, account creation) and hashed before storing.

V1.16

Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a protected location (not in source code).

V1.17

Verify that forgot password and other recovery paths send a time-limited activation token or use two factor proofs (SMS, tokens, mobile application, etc) rather than a password.

V1.18

Verify that forgot password functionality does not lock or otherwise disable the account until after the user has successfully changed their password.

V1.19

Verify that there are no shared knowledge questions/answers (so called “secret” questions and answers).

V1.20

Verify that the system can be configured to disallow the use of a configurable number of previous passwords.

Verify re-authentication, step up or adaptive authentication, SMS or other two factor application, or transaction signing is required before any application-specific sensitive operations are permitted as per the risk profile of the application.

V2: Session Management Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

SESSION MANAGEMENT

LEVELS

VERIFICATION REQUREMENT

1

2

V2.1

Verify that the framework’s default session management control implementation is used by the application.

V2.2

Verify that sessions are invalidated when the user logs out.

V2.3

Verify that sessions timeout after a specified period of inactivity.

V2.4

Verify that all pages that require authentication to access them have logout links.

V2.5

Verify that the session id is never disclosed other than in cookie headers; particularly in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.

V2.6

Verify that the session id is changed or cleared on logout.

V2.7

Verify that authenticated session tokens using cookies are protected by the use of “HttpOnly”.

V2.8

Verify that authenticated session tokens using cookies are protected with the “secure” attribute and strict transport security headers (such as Strict-Transport-Security: max-age=60000; includeSubDomains) is present.

V2.9

Verify that the session id is changed on login to prevent session fixation.

V2.10

Verify that the session id is changed on re-authentication.

V2.11

Verify that only session ids generated by the application framework are recognized as valid by the application.

V2.12

Verify that authenticated session tokens are sufficiently long and random to withstand attacks that are typical of the threats in the deployed environment.

V2.13

Verify that authenticated session tokens using cookies have their path set to an appropriately restrictive value for that site. The domain cookie attribute restriction should not be set unless for a business requirement, such as single sign on.

V2.14

Verify that the application does not permit duplicate concurrent user sessions, originating from different machines.

V2.15

Verify that sessions timeout after an administratively-configurable maximum time period regardless of activity (an absolute timeout).

V3: Access Control Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

ACCESS CONTROL

LEVELS

VERIFICATION REQUIREMENT

1

2

V3.1

Verify that users can only access secured functions or services for which they possess specific authorization.

V3.2

Verify that users can only access secured URLs for which they possess specific authorization.

V3.3

Verify that users can only access secured data files for which they possess specific authorization.

V3.4

Verify that direct object references are protected, such that only authorized objects are accessible to each user.

Verify that users can only access protected data for which they possess specific authorization (for example, protect against direct object reference tampering).

V3.7

Verify that access controls fail securely.

V3.8

Verify that the same access control rules implied by the presentation layer are enforced on the server side for that user role, such that controls and parameters cannot be re-enabled or re-added from higher privilege users.

V3.9

Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.

V3.10

Verify that all access controls are enforced on the server side.

V3.11

Verify that all access control decisions can be logged and all failed decisions are logged.

V3.12

Verify that the application or framework generates strong random anti-CSRF tokens unique to the user as part of all high value transactions or accessing sensitive data, and that the application verifies the presence of this token with the proper value for the current user when processing these requests.

V3.13

Aggregate access control protection – verify the system can protect against aggregate or continuous access of secured functions, resources, or data. For example, possibly by the use of a resource governor to limit the number of registrations per hour or to prevent the entire database from being scraped by an individual user.

V3.14

Verify that there is a centralized mechanism (including libraries that call external authorization services) for protecting access to each type of protected resource.

V4: Input Validation Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

INPUT VALIDATION

LEVELS

VERIFICATION REQUREMENT

1

2

V4.1

Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.

V4.2

Verify that the runtime environment is not susceptible to SQL Injection, or that security controls prevent SQL Injection.

V4.3

Verify that the runtime environment is not susceptible to Cross Site Scripting (XSS), or that security controls prevent XSS.

V4.4

Verify that the runtime environment is not susceptible to LDAP Injection, or that security controls prevent LDAP Injection.

V4.5

Verify that the runtime environment is not susceptible to OS Command Injection, or that security controls prevent OS Command Injection.

V4.6

Verify that all input validation failures result in input rejection or input sanitization.

V4.7

Verify that all input validation or encoding routines are performed and enforced on the server side.

V4.8

Verify that all untrusted data that are output to HTML (including HTML elements, HTML attributes, JavaScript data values, CSS blocks, and URI attributes) are properly escaped for the applicable context.

V4.9

Verify that a character set, such as UTF-8, is specified for all sources of input.

V4.10

Verify that all input data is canonicalized for all downstream decoders or interpreters prior to validation.

V4.11

If the application framework allows automatic mass parameter assignment (also called automatic variable binding) from the inbound request to a model, verify that security sensitive fields such as “accountBalance”, “role” or “password” are protected from malicious automatic binding.

V4.12

Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, environment, etc.)

V4.13

Verify that a single input validation control is used by the application for each type of data that is accepted.

V4.14

Verify that all input validation failures are logged.

V4.15

Verify that for each type of output encoding/escaping performed by the application, there is a single security control for that type of output for the intended destination.

V5: Cryptography at Rest Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

CRYPTOGRAPHY AT REST

LEVELS

VERIFICATION REQUREMENT

1

2

V5.1

Verify that all cryptographic functions used to protect secrets from the application user are implemented server side.

V5.2

Verify that all cryptographic modules fail securely.

V5.3

Verify that access to any master secret(s) is protected from unauthorized access (A master secret is an application credential stored as plaintext on disk that is used to protect access to security configuration information).

V5.4

Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module’s approved random number generator when these random values are intended to be unguessable by an attacker.

V5.5

Verify that cryptographic modules used by the application have been validated against FIPS 140-2 or an equivalent standard.

V5.6

Verify that cryptographic modules operate in their approved mode according to their published security policies.

V5.7

Verify that there is an explicit policy for how cryptographic keys are managed (e.g., generated, distributed, revoked, expired). Verify that this policy is properly enforced.

V6: Error Handling and Logging Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

ERROR HANDLING AND LOGGING

LEVELS

VERIFICATION REQUREMENT

1

2

V6.1

Verify that that the application does not output error messages or stack traces containing sensitive data that could assist an attacker, including session id and personal information.

Verify security logging controls provide the ability to log both success and failure events that are identified as security-relevant.

V6.6

Verify that each log event includes: a time stamp from a reliable source,

severity level of the event,

an indication that this is a security relevant event (if mixed with other logs),

the identity of the user that caused the event (if there is a user associated with the event),

the source IP address of the request associated with the event,

whether the event succeeded or failed, and

a description of the event.

V6.7

Verify that security logs are protected from unauthorized access and modification.

V6.8

Verify that that the application does not log application-specific sensitive data that could assist an attacker, including user’s session ids and personal or sensitive information.

V6.9

Verify that a log analysis tool is available which allows the analyst to search for log events based on combinations of search criteria across all fields in the log record format supported by this system.

V6.10

Verify that all events that include untrusted data will not execute as code in the intended log viewing software.

V6.11

Verify that there is a single logging implementation that is used by the application.

V7: Data Protection Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

DATA PROTECTION

LEVELS

VERIFICATION REQUREMENT

1

2

V7.1

Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features.

V7.2

Verify that all sensitive data is sent to the server in the HTTP message body (i.e., URL parameters are never used to send sensitive data).

V7.3

Verify that all cached or temporary copies of sensitive data sent to the client are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data (e.g., the proper no-cache and no-store Cache-Control headers are set).

V7.4

Verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data.

V7.5

Verify that the list of sensitive data processed by this application is identified, and that there is an explicit policy for how access to this data must be controlled, and when this data must be encrypted (both at rest and in transit). Verify that this policy is properly enforced.

V7.6

Verify that there is a method to remove each type of sensitive data from the application at the end of its required retention period.

V7.7

Verify the application minimizes the number of parameters sent to untrusted systems, such as hidden fields, Ajax variables, cookies and header values.

V7.8

Verify the application has the ability to detect and alert on abnormal numbers of requests for information or processing high value transactions for that user role, such as screen scraping, automated use of web service extraction, or data loss prevention. For example, the average user should not be able to access more than 5 records per hour or 30 records per day, or add 10 friends to a social network per minute.

V8: Comunications Security Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

COMMUNICATIONS SECURITY

LEVELS

VERIFICATION REQUREMENT

1

2

V8.1

Verify that a path can be built from a trusted CA to each Transport Layer Security (TLS) server certificate, and that each server certificate is valid.

V8.2

Verify that TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions.

V8.3

Verify that backend TLS connection failures are logged.

V8.4

Verify that all connections to external systems that involve sensitive information or functions are authenticated.

V8.5

Verify that all connections to external systems that involve sensitive information or functions use an account that has been set up to have the minimum privileges necessary for the application to function properly.

V8.6

Verify that failed TLS connections do not fall back to an insecure connection.

V8.7

Verify that certificate paths are built and verified for all client certificates using configured trust anchors and revocation information.

Verify that specific character encodings are defined for all connections (e.g., UTF-8).

V9: HTTP Security Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

HTTP SECURITY

LEVELS

VERIFICATION REQUREMENT

1

2

V9.1

Verify that the application accepts only a defined set of HTTP request methods, such as GET and POST and unused methods are explicitly blocked.

V9.2

Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8).

V9.3

Verify that HTTP headers and / or other mechanisms for older browsers have been included to protect against click jacking attacks

V9.4

Verify that HTTP headers in both requests and responses contain only printable ASCII characters.

V10: Malicious Controls Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

MALICIOUS CONTROLS

LEVELS

VERIFICATION REQUREMENT

1

2

V10.1

Verify that no malicious code is in any code that was either developed or modified in order to create the application.

V10.2

Verify that the integrity of interpreted code, libraries, executables, and configuration files is verified using checksums or hashes.

V10.3

Verify that all code implementing or using authentication controls is not affected by any malicious code.

V10.4

Verify that all code implementing or using session management controls is not affected by any malicious code.

V10.5

Verify that all code implementing or using access controls is not affected by any malicious code.

V10.6

Verify that all input validation controls are not affected by any malicious code.

V10.7

Verify that all code implementing or using output validation controls is not affected by any malicious code.

V10.8

Verify that all code supporting or using a cryptographic module is not affected by any malicious code.

V10.9

Verify that all code implementing or using error handling and logging controls is not affected by any malicious code.

V10.10

Verify all malicious activity is adequately sandboxed.

V10.11

Verify that sensitive data is rapidly sanitized from memory as soon as it is no longer needed

V11: Business Logic Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

BUSINESS LOGIC

LEVELS

VERIFICATION REQUREMENT

1

2

V11.1

Verify the application processes or verifies all high value business logic flows in a trusted environment, such as on a protected and monitored server.

V11.2

Verify the application does not allow spoofed high value transactions, such as allowing Attacker User A to process a transaction as Victim User B by tampering with or replaying session, transaction state, transaction or user IDs.

V11.3

Verify the application does not allow high value business logic parameters to be tampered with, such as (but not limited to): price, interest, discounts, PII, balances, stock IDs, etc.

V11.4

Verify the application has defensive measures to protect against repudiation attacks, such as verifiable and protected transaction logs, audit trails or system logs, and in highest value systems real time monitoring of user activities and transactions for anomalies.

V11.5

Verify the application protects against information disclosure attacks, such as direct object reference, tampering, session brute force or other attacks.

V11.6

Verify the application has sufficient detection and governor controls to protect against brute force (such as continuously using a particular function) or denial of service attacks.

V11.7

Verify the application has sufficient access controls to prevent elevation of privilege attacks, such as allowing anonymous users from accessing secured data or secured functions, or allowing users to access each other’s details or using privileged functions.

V11.8

Verify the application will only process business logic flows in sequential step order, with all steps being processed in realistic human time, and not process out of order, skipped steps, process steps from another user, or too quickly submitted transactions.

V11.9

Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.

V11.10

Verify the application has business limits and enforces them in a trusted location (as on a protected server) on a per user, per day or daily basis, with configurable alerting and automated reactions to automated or unusual attack. Examples include (but not limited to): ensuring new SIM users don’t exceed $10 per day for a new phone account, a forum allowing more than 100 new users per day or preventing posts or private messages until the account has been verified, a health system should not allow a single doctor to access more patient records than they can reasonably treat in a day, or a small business finance system allowing more than 20 invoice payments or $1000 per day across all users. In all cases, the business limits and totals should be reasonable for the business concerned. The only unreasonable outcome is if there are no business limits, alerting or enforcement.

V12: Files and Resources Verification Requirements

The table below defines the corresponding verification requirements that apply for each of the verification levels. Verification requirements for Level 0 are not defined by this standard.

FILES AND RESOURCES

LEVELS

VERIFICATION REQUREMENT

1

V12.1

(Formerly V11.1) Verify that URL redirects and forwards do not include unvalidated data.

Verify that files obtained from untrusted sources are scanned by anti-virus scanners to prevent upload of known malicious content.

V12.4

Verify that parameters obtained from untrusted sources are not used in manipulating filenames, pathnames or any file system object without first being canonicalized and input validated to prevent local file inclusion attacks.

V12.5

Verify that parameters obtained from untrusted sources are canonicalized, input validated, and output encoded to prevent remote file inclusion attacks, particularly where input could be executed, such as header, source, or template inclusion

OWASP Top 10 – 2013

The threat landscape for applications security constantly changes. Key factors in this evolution are advances made by attackers, the release of new technologies with new weaknesses as well as more built in defenses, and the deployment of increasingly complex systems. In this 2013 release, we made the following changes:

What Changed From 2010 to 2013?

1) Broken Authentication and Session Management moved up in prevalence based on our data set,. Probably because this area is being looked at harder, not because issues are actually more prevalent. This caused Risks A2 and A3 to switch places.2) Cross-Site Request Forgery (CSRF) moved down in prevalence based on our data set from 2010-A5 to 2013-A8. This is believed to have occurred 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.3) Broadened Failure to Restrict URL Access from the 2010 OWASP Top 10 to be more inclusive:

2010-A8: Failure to Restrict URL Access is now 2013-A7: Missing Function Level Access Control – to cover all of function level access control. There are many ways to specify which function is being accessed, not just the URL.

This new category was created by merging 2010-A7 – Insecure Cryptographic Storage & 2010-A9 – Insufficient Transport 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.

4) Added: 2013-A9: Using Known Vulnerable Components:

This issue was mentioned as part of 2010-A6 – Security Misconfiguration, but is now a category in its own right as the growth and depth of component based development has significantly increased the risk of using known vulnerable components.

The Web Application Security Consortium (WASC) is a worldwide organization devoted to the establishment, refinement and promotion of Internet security standards. The consortium, which was founded in January 2004, consists of independent members as well as those associated with corporations, government agencies and academic institutions.

The WASC’s mandate includes researching, discussing, and publishing information about Web application security issues. The organization educatesh individuals and enterprises about such issues and the countermeasures that can be taken against specific threats, and acting as an advocate for users of the Internet, and in particular, for individuals and organizations devoted to Web application security. The WASC is vendor-neutral, although members may belong to corporations involved in the research, development, design, and distribution of Web security related products.

This project’s goal is to create a “best practices” web application penetration testing framework which users can implement in their own organizations and a “low level” web application penetration testing guide that describes how to find certain issues.