asvs/v1-encoding-and-sanitization

31 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

V1.1.1 Input decoding once in canonical form

Requirement 1.1.1 applies at Level 2. The application must verify that input is decoded or unescaped into a canonical form only once, it is only decoded when encoded data in that form is expected, and that this is done before processing the input further, for example it is not performed after input validation or sanitization.

V1.1.2 Output encoding as final step

Requirement 1.1.2 applies at Level 2. The application must verify that output encoding and escaping is performed either as a final step before being used by the interpreter for which it is intended or by the interpreter itself.

V1.2.1 HTTP response output encoding for context

Requirement 1.2.1 applies at Level 1. The application must verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, CSS, or HTTP header fields, to avoid changing the message or document structure.

V1.2.2 URL encoding for dynamic URLs

Requirement 1.2.2 applies at Level 1. The application must verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path parameters). Only safe URL protocols must be permitted (e.g., disallow javascript: or data:).

V1.2.3 JavaScript and JSON output encoding

Requirement 1.2.3 applies at Level 1. The application must verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document structure and to avoid JavaScript and JSON injection.

V1.2.4 Parameterized database queries

Requirement 1.2.4 applies at Level 1. The application must verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from SQL Injection and other database injection attacks. This is also relevant when writing stored procedures.

V1.2.5 OS command injection protection

Requirement 1.2.5 applies at Level 1. The application must verify that it protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding.

V1.2.6 LDAP injection protection

Requirement 1.2.6 applies at Level 2. The application must verify that it protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented.

V1.2.7 XPath injection protection

Requirement 1.2.7 applies at Level 2. The application must verify that it is protected against XPath injection attacks by using query parameterization or precompiled queries.

V1.2.8 LaTeX processor security configuration

Requirement 1.2.8 applies at Level 2. The application must verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX injection attacks.

V1.2.9 Regular expression special character escaping

Requirement 1.2.9 applies at Level 2. The application must verify that it escapes special characters in regular expressions (typically using a backslash) to prevent them from being misinterpreted as metacharacters.

V1.2.10 CSV and Formula Injection protection

Requirement 1.2.10 applies at Level 3. The application must verify that it is protected against CSV and Formula Injection. The application must follow the escaping rules defined in RFC 4180 sections 2.6 and 2.7 when exporting CSV content. Additionally, when exporting to CSV or other spreadsheet formats (such as XLS, XLSX, or ODF), special characters (including '=', '+', '-', '@', '\t' (tab), and '\0' (null character)) must be escaped with a single quote if they appear as the first character in a field value.

V1.3.1 WYSIWYG HTML input sanitization

Requirement 1.3.1 applies at Level 1. The application must verify that all untrusted HTML input from WYSIWYG editors or similar is sanitized using a well-known and secure HTML sanitization library or framework feature.

V1.3.2 Avoiding dynamic code execution

Requirement 1.3.2 applies at Level 1. The application must verify that it avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no alternative, any user input being included must be sanitized before being executed.

V1.3.3 Dangerous context sanitization

Requirement 1.3.3 applies at Level 2. The application must verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which are safe for this context and trimming input which is too long.

V1.3.4 SVG scriptable content validation

Requirement 1.3.4 applies at Level 2. The application must verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or sanitized to contain only tags and attributes (such as draw graphics) that are safe for the application, and do not contain scripts and foreignObject.

V1.3.5 Template language content sanitization

Requirement 1.3.5 applies at Level 2. The application must verify that it sanitizes or disables user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.

V1.3.6 SSRF protection

Requirement 1.3.6 applies at Level 2. The application must verify that it protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service.

V1.3.7 Template injection protection

Requirement 1.3.7 applies at Level 2. The application must verify that it protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated.

V1.3.8 JNDI injection prevention

Requirement 1.3.8 applies at Level 2. The application must verify that it appropriately sanitizes untrusted input before use in Java Naming and Directory Interface (JNDI) queries and that JNDI is configured securely to prevent JNDI injection attacks.

V1.3.9 Memcache injection prevention

Requirement 1.3.9 applies at Level 2. The application must verify that it sanitizes content before it is sent to memcache to prevent injection attacks.

V1.3.10 Format string sanitization

Requirement 1.3.10 applies at Level 2. The application must verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed.

V1.3.11 Mail system injection prevention

Requirement 1.3.11 applies at Level 2. The application must verify that it sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.

V1.3.12 Regular expression ReDoS prevention

Requirement 1.3.12 applies at Level 3. The application must verify that regular expressions are free from elements causing exponential backtracking, and ensure untrusted input is sanitized to mitigate ReDoS or Runaway Regex attacks.

V1.4.1 Memory-safe string operations

Requirement 1.4.1 applies at Level 2. The application must verify that it uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.

V1.4.2 Integer overflow prevention

Requirement 1.4.2 applies at Level 2. The application must verify that sign, range, and input validation techniques are used to prevent integer overflows.

V1.4.3 Use-after-free prevention

Requirement 1.4.3 applies at Level 2. The application must verify that dynamically allocated memory and resources are released, and that references or pointers to freed memory are removed or set to null to prevent dangling pointers and use-after-free vulnerabilities.

V1.5.1 XXE prevention through XML parser configuration

Requirement 1.5.1 applies at Level 1. The application must verify that it configures XML parsers to use a restrictive configuration and that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.

V1.5.2 Safe deserialization of untrusted data

Requirement 1.5.2 applies at Level 2. The application must verify that deserialization of untrusted data enforces safe input handling, such as using an allowlist of object types or restricting client-defined object types, to prevent deserialization attacks. Deserialization mechanisms that are explicitly defined as insecure must not be used with untrusted input.

V1.5.3 Consistent parser behavior across different parsers

Requirement 1.5.3 applies at Level 3. The application must verify that different parsers used in the application for the same data type (e.g., JSON parsers, XML parsers, URL parsers), perform parsing in a consistent way and use the same character encoding mechanism to avoid issues such as JSON Interoperability vulnerabilities or different URI or file parsing behavior being exploited in Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks.

V1 chapter control objective

The V1 Encoding and Sanitization chapter addresses the most common web application security weaknesses related to the unsafe processing of untrusted data. Such weaknesses can result in various technical vulnerabilities, where untrusted data is interpreted according to the syntax rules of the relevant interpreter.

Give your agent this brain