OWASP ASVS 2013 Beta _v1

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.

LEVELS

ACCESS CONTROL

VERIFICATION REQUREMENT

Verify that users can only access secured functions or services for which they

V3.1

possess specific authorization.

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

V3.2

authorization.

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

V3.3

specific authorization.

Verify that direct object references are protected, such that only authorized

V3.4

objects are accessible to each user.

Verify that users can only access protected data for which they possess

V3.6 specific authorization (for example, protect against direct object reference tampering).

Verify that the same access control rules implied by the presentation layer

V3.8 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.

Verify that all user and data attributes and policy information used by access

V3.9

controls cannot be manipulated by end users unless specifically authorized.

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

V3.11

are logged.

17

LEVELS

ACCESS CONTROL

VERIFICATION REQUREMENT

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

V3.12

sensitive data, and that the application verifies the presence of this token with the proper value for the current user when processing these requests.

Aggregate access control protection – verify the system can protect against aggregate or continuous access of secured functions, resources, or data. For

V3.13 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.

Verify that there is a centralized mechanism (including libraries that call

V3.14 external authorization services) for protecting access to each type of protected resource.

Table 3 - OWASP ASVS Access Control Requirements (V3)

18

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.

LEVELS

INPUT VALIDATION

VERIFICATION REQUREMENT

Verify that the runtime environment is not susceptible to buffer overflows, or

V4.1

that security controls prevent buffer overflows.

Verify that the runtime environment is not susceptible to SQL Injection, or

V4.2

that security controls prevent SQL Injection.

Verify that the runtime environment is not susceptible to Cross Site Scripting

V4.3

(XSS), or that security controls prevent XSS.

Verify that the runtime environment is not susceptible to LDAP Injection, or

V4.4

that security controls prevent LDAP Injection.

Verify that the runtime environment is not susceptible to OS Command

V4.5

Injection, or that security controls prevent OS Command Injection.

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

V4.6

sanitization.

Verify that all input validation or encoding routines are performed and

V4.7

enforced on the server side.

Verify that all untrusted data that are output to HTML (including HTML

V4.8 elements, HTML attributes, JavaScript data values, CSS blocks, and URI attributes) are properly escaped for the applicable context.

Verify that all input data is canonicalized for all downstream decoders or

V4.10

interpreters prior to validation.

If the application framework allows automatic mass parameter assignment

(also called automatic variable binding) from the inbound request to a

V4.11

model, verify that security sensitive fields such as “accountBalance”, “role” or “password” are protected from malicious automatic binding.

19

LEVELS

INPUT VALIDATION

VERIFICATION REQUREMENT

Verify that the application has defenses against HTTP parameter pollution

attacks, particularly if the application framework makes no distinction about

V4.12

the source of request parameters (GET, POST, cookies, headers, environment, etc.)

Verify that a single input validation control is used by the application for

V4.13

each type of data that is accepted.

Verify that for each type of output encoding/escaping performed by the

V4.15 application, there is a single security control for that type of output for the intended destination.

Table 4 - OWASP ASVS Input Validation Requirements (V4)

20

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.

LEVELS

CRYPTOGRAPHY AT REST

VERIFICATION REQUREMENT

Verify that all cryptographic functions used to protect secrets from the

V5.1

application user are implemented server side.

Verify that access to any master secret(s) is protected from unauthorized

V5.3 access (A master secret is an application credential stored as plaintext on disk that is used to protect access to security configuration information).

Verify that all random numbers, random file names, random GUIDs, and

random strings are generated using the cryptographic module’s approved

V5.4

random number generator when these random values are intended to be unguessable by an attacker.

Verify that cryptographic modules used by the application have been

V5.5

validated against FIPS 140-2 or an equivalent standard.

Verify that cryptographic modules operate in their approved mode

V5.6

according to their published security policies.

Verify that there is an explicit policy for how cryptographic keys are

V5.7 managed (e.g., generated, distributed, revoked, expired). Verify that this policy is properly enforced.

Table 5 - OWASP ASVS Cryptography at Rest Requirements (V5)

21

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.

LEVELS

ERROR HANDLING AND LOGGING

VERIFICATION REQUREMENT

Verify that that the application does not output error messages or stack

V6.1 traces containing sensitive data that could assist an attacker, including session id and personal information.

V6.2

Verify that all error handling is performed on trusted devices

V6.3

Verify that all logging controls are implemented on the server.

V6.4

Verify that error handling logic in security controls denies access by default.

Verify security logging controls provide the ability to log both success and

V6.5

failure events that are identified as security-relevant.

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

V6.6

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.

Verify that security logs are protected from unauthorized access and

V6.7

modification.

Verify that that the application does not log application-specific sensitive

V6.8 data that could assist an attacker, including user’s session ids and personal or sensitive information.

22

LEVELS

ERROR HANDLING AND LOGGING

VERIFICATION REQUREMENT

Verify that a log analysis tool is available which allows the analyst to search

V6.9 for log events based on combinations of search criteria across all fields in the log record format supported by this system.

Verify that all events that include untrusted data will not execute as code in

V6.10

the intended log viewing software.

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

V6.11

application.

Table 6 - OWASP ASVS Error Handling and Logging Requirements (V6)

23

V8: Communications 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.

LEVELS

COMMUNICATIONS SECURITY

VERIFICATION REQUREMENT

Verify that a path can be built from a trusted CA to each Transport Layer

V8.1

Security (TLS) server certificate, and that each server certificate is valid.

Verify that TLS is used for all connections (including both external and

V8.2 backend connections) that are authenticated or that involve sensitive data or functions.

V8.3

Verify that backend TLS connection failures are logged.

Verify that all connections to external systems that involve sensitive

V8.4

information or functions are authenticated.

Verify that all connections to external systems that involve sensitive

V8.5 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.

Verify that certificate paths are built and verified for all client certificates

V8.7

using configured trust anchors and revocation information.

Verify that there is a single standard TLS implementation that is used by the

application that is configured to operate in an approved mode of operation

V8.8

(See http://csrc.nist.gov/groups/STM/cmvp/documents/fips140- 2/FIPS1402IG.pdf ).

Verify that specific character encodings are defined for all connections (e.g.,

V8.9

UTF-8).

Table 8 - OWASP ASVS Communications Security Requirements (V8)

25