ASVS V4 Level 1 Verification breakdown

ASVS V4 Level 1

The ASVS V4 released in March 2019 is an update and extension of the ASVS Level 3. You can read about the still perfectly valid and comprehensive Level 3 components in our blog post here.

This blog post is a breakdown of the ASVS V4 Level 1 specific verification requirements. In Level 1 there are 133 individual verification’s, Level 2 adds ~130 more.

Peppered in this Blog post are some images of our Universe taken at the Astronomy Photo of the Year Exhibition. Why? Just because the images are amazing and should be shared.

Level 1 really does give a good solid coverage of application security but I think people are put off because it is the “most basic” level.

Our Moon in Colour. A compilation of 25 Images.

Level 1 is akin to the OWASP top 10 vulnerabilities and is completely penetration testable.

Level 2 moves beyond an external company evaluating the application security and become a partnership working in conjunction with each other towards the secure architecture and development of your product.

Images from the live document showing the inclusion of links to additional external resources.

The following three images show the additional value OIC Solutions have added to this otherwise open source document.

The Hyperlinks that appear in all 13 Level 1 sections are researched, verified and add value to the client through time saving searches and providing clear clarification and explanations.

The Andromeda Galaxy.

ASVS V4 Level 1 specific verification’s

Solar eclipse. Photo taken @ 8 minute intervals.

 

ASVS v4 Level 1 Standard

Requirement / Recommendation or Best Practice

Authentication Verification Requirements

 

2.1.1

Minimum password length is 12 characters without MFA

Minimum password length is 8 characters with MFA

Is MFA deactivatable by users?

OWASP / NIST suggest a 10 character minimum.

2.1.2

64 characters or longer passwords possible?

2.1.3

Passwords can contain spaces?

2.1.4

Unicode characters are allowed in password?

2.1.5 & 2.1.6

Users can change their password?

 

Both the user’s current and new password are required to change password?

2.1.7

Newly chosen passwords are checked against a list of commonly known passwords?

Use a list such as this one of 10000 Weakest passwords as a source to check.

New password is denied if present on the list?

Is an explanation given as to the reason for password rejection?

2.1.8

Application has a “password strength meter” to assist users in picking a strong password?

2.1.9

Passwords should not require speci@l characters or UPPER or lower case characters or Numbers.

2.1.10

Password rotation or password history checks are not necessary.

2.1.11

Password can be pasted and external password managers are permitted?

2.1.12

Entire password is temporarily viewable?

Last character of password is temporarily viewable?

2.2.1

No more than 100 failed access attempts per hour are possible on a single account?

2.2.2

If SMS and Email are used they are only used for secondary verification and transaction approvals?

2.2.3

Users are notified of account updates including credential resets, email changes, or logging in from unknown or risky locations?

2.3.1

Initial “random” passwords or activation codes are at least 6 characters in length?

May contain both letters and numbers?

Have a short life span?

Cannot be used as a permanent password?

2.5.1

System generated initial activation or recovery secret is not sent in clear text?

2.5.2

Password hints or secret question / answer are not used in the application?

2.5.3

Credential recovery does not reveal current password in any way?

2.5.4

Ensure that shared or default accounts are not present (e.g. “root”, “admin”, or “sa”.

2.5.5

If an authentication factor is changed, is the user notified?

2.7.1

SMS or Phone authenticators are not the default and stronger alternatives like push notifications are offered first.

2.7.2

Verify that out of band requests, codes or tokens only function with the original request and only have a 10 minutes lifespan.

2.8.1

If OTP functionality is used, the OTPs have a defined life span before expiring?

Does not explicitly specify a value for life span.

Session Management Verification Requirements

 

3.1.1

Application never reveals session tokens in URL parameters or error messages?

3.2.1

Application generates a new session token upon user authentication?

3.2.2

Session tokens possess a minimum of 64 bits of entropy?

3.2.3

Session tokens are only stored in the browser using secure methods?

3.3.1

Session logout and Session timeouts invalidate session tokens? Further information available here.

3.3.2

If users can remain logged in, re-authentication is forced after 30 days?

3.4.1

Cookie-based session tokens have “secure” attribute set?

3.4.2

Cookie-based session tokens have the “HttpOnly” attribute set?

3.4.3

Cookie-based session tokens have the “SameSite” attribute set?

Aimed to limit exposure to CSRF attacks.

3.4.4

Cookie-based session tokens use “__Host-” prefix.

Aimed to provide session cookie confidentiality.

3.4.5

Ensure that path attribute in the cookie-based session tokens use the most precise path possible if the application is published under a Domain Name with other applications.

3.7.1

Before any sensitive transactions or account modifications are allowed, the application confirms a valid logon session is active, re-authentication is enforced or secondary verification is undertaken.

Access Control Verification Requirements

 

4.1.1

Does the application enforce access control rules on a trusted service layer?

4.1.2

Are all user and data attributes and policy information used by access controls protected from unauthorised end user manipulation?

4.1.3

Verify the application uses the principle of “least privilege”. Can users only access function and resources to which they have specifically been given access.

4.1.4

Verify the application uses the principle of “deny by default”. New users/roles start with minimal or no permissions and do not receive additional permissions or access to additional features or components without being specifically assigned to them?

4.1.5

Verify that access controls “fail securely”.

4.2.1

Verify that sensitive data and APIs are protected against direct object attacks.

Are direct objects references such as filenames or ids included in GET URLs or POST parameters and open to unauthorised manipulation?

4.2.2

  1. Does the application enforce a strong anti-CSRF mechanism to protect authenticated functionality?
  2. Does the application enforce an effective anti-automation or anti-CSRF protection against unauthenticated functionality?

4.3.1

Administrator interfaces have multi factor authentication in place?

4.3.2

  1. Verify that directory browsing is disabled unless a crucial part of the applications functionality.
  2. Applications should not allow the discovery or disclosure of directory metadata, such as Thumbs.db, .git or .svn folders.

Validation, Sanitization & Encoding Verification

 

5.1.1

Verify defences against HTTP Parameter pollution attacks.

5.1.2

Verify defences against Mass Parameter Assignment attacks.

5.1.3

Verify that input is validated through Whitelisting.

This should include all HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc. Further information is available here.

5.1.4

Verify that data inputted is strongly typed and validated against a defined schema. E.g. a credit card number is checked to be 16 digits in length. Further information is available here.

5.1.5

Verify that URL redirects and forwards only allow whitelisted destinations, or display a warning when redirecting to potentially untrusted content.

5.2.1

Verify that all untrusted HTML input is properly sanitized with an HTML Sanitizer Library.

5.2.2

Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.

5.2.3

If Mail Systems are part of the application, confirm that the application sanitizes user inputs before passing to the mail system to protect against SMTP or IMAP injection.

5.2.4

Verify that the application does not employ the eval() or other dynamic code execution features. If there is no alternative, input must be sanitized or sandboxed before execution.

5.2.5

Verify the application is protected from Template Injection attacks through the use of sanitization or sandboxing.

5.2.6

Verify the application is protected from Server Side Request Forgery (SSRF) attacks. Validate or sanitize untrusted data or HTTP metadata such as filenames and URL input fields. Protect with Whitelisting of protocols, domains, paths and ports.

5.2.7

Verify the application sanitizes, sandboxes or disables user supplied SVG scriptable content. Further information is available here.

5.2.8

Verify the application sanitizes, sandboxes or disables user supplied scriptable or expression template language content, such as Markdown, CSS or XSL style-sheets.

5.3.1

Verify that output encoding especially from untrusted inputs is relevant for the interpreter and context required. Use the right tool for the right job with regards to HTML values, HTML attributes, JavaScript, URL Parameters, HTTP headers and SMTP.

5.3.2

Verify that output encoding preserve the users chosen character set and locale.

5.3.3

Verify that output encoding protects against Reflected, Stored and DOM Based Cross Site Scripting (XSS) attacks.

5.3.4

Safeguard against SQL (database) Injection attacks by using parameterized queries.

5.3.5

Verify the implementation of SQL escaping.

5.3.6

Verify the application protects against JSON and JavaScript injection attacks.

5.3.7

Verify the application is not vulnerable to LDAP Injection attacks.

5.3.8

Verify the application is not vulnerable to OS Command Injection attacks.

5.3.9

Verify the application is not vulnerable to Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.

5.3.10

Verify the application is not vulnerable to XPath or XML Injection attacks.

5.5.1

Verify that serialised objects are encrypted or use integrity checks to prevent data tampering or hostile object creation. Further information is available here.

5.5.2

Verify that the application correctly restricts XML parsers to solely use the most restrictive configuration possible and to ensure the unsafe features such as resolving external entities are disabled to prevent XML External Entity (XXE) attacks.

5.5.3

Verify that deserialization of untrusted data is avoided in both custom code and third-party libraries.

5.5.4

Verify that when JSON is parsed in browsers or JavaScript based backends, JSON.parse is used to parse the JSON document.

Do not use eval() to parse JSON.

Stored Cryptography Verification Requirements

 

6.2.1

Verify that cryptographic modules fail securely and do not enable Padding Oracle attacks.

Error Handling and Logging Verification Requirements

 

7.1.1

Verify that the application does not perform logging of credentials or payment details.

Session tokens must only be stored in Logs in an irreversible, hashed form.

7.1.2

Verify that the application does not log other sensitive data as defined under local privacy or EU laws and contrary to the organization’s Security Policies.

7.4.1

Verify that a “generic message” is displayed when an unexpected or security sensitive error occurs. Further information is available here & here.

If practical the error message should also display a unique ID number that can assist support staff for investigation purposes.

Data Protection Verification Requirements

 

8.2.1

Verify that sensitive data is not cached by the Internet Browser.

8.2.2

Verify that client side storage such as HTML5 Local Storage, session storage, regular or flash cookies do not contain PII or other sensitive information.

8.2.3

Verify that authenticated data is cleared from client storage after the client session is finished.

8.3.1

Verify that sensitive data is transmitted to the server in HTTP message body or headers.

Confirm that query string parameters from any HTTP verb do not contain sensitive data.

8.3.2

Verify that users have a method to remove or export their data on demand

8.3.3

Verify that users are provided a clean language explanation regarding the collection and use of their supplied personal information.

Verify users have to “opt-in” consent for the data to be used in any way.

8.3.4

Verify that all sensitive data created and processed by the application has been identified, and ensure there is a policy in place on how to deal with sensitive data.

Communication Verification Requirements

 

9.1.1

Verify that call client connectivity uses secured TLS and that it does not fall back to insecure or unencrypted protocols.

9.1.2

Verify using online testing tools that the TLS algorithms and protocols are the preferred versions to use.

9.1.3

Verify that old versions of SSL and TLS are not in use.

The latest TLS version should be the preferred cipher suite.

Malicious Code Verification Requirements

 

10.3.1

Verify that if the application has a client or server auto update feature that updates are obtained over secure channels and digitally signed. The digital signature of the update must be validated before installation.

10.3.2

Verify that the application uses integrity protections such as code signing. The application must not load or execute code from untrusted sources.

10.3.3

Verify that the application has protection against subdomain takeovers.

Business Logic Verification Requirements

 

11.1.1

Verify that the application will only process business logic flows for the same user in sequential steps. Further information is available here.

11.1.2

Verify that the application will only process business logic flows with all steps being processed in realistic human time. Further information is available here.

11.1.3

Verify that the application has appropriate limits for business actions or transactions which are correctly enforced on a per user basis.

11.1.4

Verify that the application has sufficient anti-automation controls. Further information is available here & here & here.

11.1.5

Verify the application has business logic limits or validation to protect against the risk and threats identified using threat modelling. Further information is available here.

File and Resources Verification Requirements

 

12.1.1

Verify limits are set on file size uploads. Further information is available here.

12.3.1

Verify that user-submitted file metadata like filename and path cannot be leveraged to achieve path traversal.

12.3.2

Verify that user-submitted filename metadata is validated or ignored to prevent Local File Inclusion (LFI).

12.3.3

Verify that user-submitted filename metadata is validated or ignored to prevent Remote File Inclusion (RFI) which could allow Server Side Request Forgery (SSRF).

12.3.4

Verify that user-submitted filename metadata is validated or ignored to protect against reflective file download (RFD) attacks.

This applies to JSON, JSONP or URL parameters.

Response Content-Type headers should be text/plain and the Content-Disposition header should have a fixed filename. Further information is available here.

12.3.5

Verify that untrusted file metadata is not used directly with system API or Libraries to protect against OS command injection.

12.4.1

Verify that files obtained from untrusted sources (e.g. User uploads) are not stored in the web root with lax or loose permissions.

12.4.2

Verify that files obtained from untrusted sources (e.g. User uploads) are scanned by antivirus.

12.5.1

Verify that the web root tier will only serve files with specific file extensions.

.bak, .swp. .zip, .tar.gz etc should be blocked unless specifically required for application functionality.

12.5.2

Verify that direct requests to uploaded files will not be executed as HTML/JavaScript content.

12.6.1

Verify that the application server uses a Whitelist of resources or systems that it can send request of load data/file from.

API and Web Service Verification Requirements

 

13.1.1

Verify that the application uses the same encodings and parsers in order to protect against the exploitation of different URI or file parsing behaviors that could lead to Server Side Request Forgery (SSRF) and Remote File Inclusion (RFI) attacks. Further information is available here.

13.1.2

Verify that access to administration and management functions are only available to authorised administrators.

13.1.3

Verify that API URLs do not expose sensitive data like session tokens or API Keys.

13.2.1

Verify that RESTful HTTP methods are safe from user manipulation such as using DELETE or PUT commands on protected API Resources. Further information is available here.

13.2.2

Verify the application uses JSON schema validation before accepting input. Further information is available here.

13.2.3

Verify that RESTful web services that use cookies are protected from Cross-site request forgery (CSRF).

13.3.1

Verify that XSD schema validation happens to ensure a properly formed XML document. Further information is available here.

Configuration Verification Requirements

 

14.2.1

Verify that components are up to date, ideally using a dependency checker. Further information is available here.

14.2.2

Verify that all unneeded features, samples, default files and user accounts have been removed.

14.2.3

Verify that if web application assets, such as JavaScript libraries, CSS stylesheets or web fonts, are hosted externally on a content delivery network (CDN), subresource Integrity (SRI) is used to validate the assets integrity.

14.3.1

Verify that the web application server error messages use customised responses to limit unintended security information disclosure. Further information is available here.

14.3.2

Verify that the web application server debug mode is disabled in the production environment.

14.3.3

Verify that HTTP responses or HTTP Headers do not expose detailed version information about system components.

14.4.1

Verify that HTTP Responses contain a content type header specifying a safe character set. Further information is available here & here.

14.4.2

Verify that API resources contain Content-Disposition: attachment; filename=”api.json” (or other appropriate filename for the content type). Further information is available here & here.

14.4.3

Verify that there is a content security policy (CSPv2) in place. Further information is available here.

14.4.4

Verify that all responses contain X-Content-Type-Options: nosniff. Further information is available here.

14.4.5

Verify that HTTP Strict Transport Security headers are included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.

14.4.6

Verify that a suitable “Referrer-Policy” header is included, such as “no-referrer” or “same-origin”.

14.4.7

Verify that a suitable X-Frame-Options or Content-Security-Policy: frame-ancestors header is in use where content should not be embedded in a third party site.

14.5.1

Verify the web application only accepts the HTTP methods in use by the application or API, including pre-flight OPTIONS.

14.5.2

Verify that the supplied Origin Header is not used for authentication or access control decisions.

14.5.3

Verify that the Cross-domain resource sharing (CORS) Access-control-allow-origin header uses a string whitelist of trusted domains.

Jupiter and it’s moons Io and Ganymede.
Photo taken from the UK with kit in Chile.
Summary
Service Type
ASVS V4 IT Security policy creation
Provider Name
oic solutions,
Description

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Phone +44 (0) 207 993 2239 E-mail info@oicsolutions.co.uk
%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close