Skip to content

Latest commit

 

History

History
109 lines (82 loc) · 13.3 KB

0x13-V5-Validation-Sanitization-Encoding.md

File metadata and controls

109 lines (82 loc) · 13.3 KB

V5 Validation, Sanitization and Encoding

Control Objective

The most common web application security weakness is the failure to properly validate input coming from the client or the environment before directly using it without any output encoding. This weakness leads to almost all of the significant vulnerabilities in web applications, such as Cross-Site Scripting (XSS), SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.

Ensure that a verified application satisfies the following high-level requirements:

  • Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.
  • Input data is strongly typed, validated, range or length checked, or at worst, sanitized or filtered.
  • Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.

With modern web application architecture, output encoding is more important than ever. It is difficult to provide robust input validation in certain scenarios, so the use of safer API such as parameterized queries, auto-escaping templating frameworks, or carefully chosen output encoding is critical to the security of the application.

V5.1 Input Validation

Properly implemented input validation controls, using positive allow lists and strong data typing, can eliminate more than 90% of all injection attacks. Length and range checks can reduce this further. Building in secure input validation is required during application architecture, design sprints, coding, and unit and integration testing. Although many of these items cannot be found in penetration tests, the results of not implementing them are usually found in V5.3 - Output encoding and Injection Prevention Requirements. Developers and secure code reviewers are recommended to treat this section as if L1 is required for all items to prevent injections.

# Description L1 L2 L3 CWE
5.1.1 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, or environment variables). ✓ ✓ ✓ 235
5.1.2 Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. (C5) ✓ ✓ ✓ 915
5.1.3 Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). (C5) ✓ ✓ ✓ 20
5.1.4 Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). (C5) ✓ ✓ ✓ 20
5.1.5 Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content. ✓ ✓ ✓ 601

V5.2 Sanitization and Sandboxing

# Description L1 L2 L3 CWE
5.2.1 Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. (C5) ✓ ✓ ✓ 116
5.2.2 Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length. ✓ ✓ ✓ 138
5.2.3 Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. ✓ ✓ ✓ 147
5.2.4 Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed. ✓ ✓ ✓ 95
5.2.5 Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed. ✓ ✓ ✓ 94
5.2.6 Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports. ✓ ✓ ✓ 918
5.2.7 Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject. ✓ ✓ ✓ 159
5.2.8 Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar. ✓ ✓ ✓ 94

V5.3 Output Encoding and Injection Prevention

Output encoding close or adjacent to the interpreter in use is critical to the security of any application. Typically, output encoding is not persisted, but used to render the output safe in the appropriate output context for immediate use. Failing to output encode will result in an insecure, injectable, and unsafe application.

# Description L1 L2 L3 CWE
5.3.1 Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). (C4) ✓ ✓ ✓ 116
5.3.2 Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. (C4) ✓ ✓ ✓ 176
5.3.3 Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. (C4) ✓ ✓ ✓ 79
5.3.4 Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. (C3) ✓ ✓ ✓ 89
5.3.5 Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. (C3, C4) ✓ ✓ ✓ 89
5.3.6 Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation. (C4) ✓ ✓ ✓ 830
5.3.7 Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. (C4) ✓ ✓ ✓ 90
5.3.8 Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. (C4) ✓ ✓ ✓ 78
5.3.9 Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks. ✓ ✓ ✓ 829
5.3.10 Verify that the application protects against XPath injection or XML injection attacks. (C4) ✓ ✓ ✓ 643

Note: Using parameterized queries or escaping SQL is not always sufficient; table and column names, ORDER BY and so on, cannot be escaped. The inclusion of escaped user-supplied data in these fields results in failed queries or SQL injection.

Note: The SVG format explicitly allows ECMA script in almost all contexts, so it may not be possible to block all SVG XSS vectors completely. If SVG upload is required, we strongly recommend either serving these uploaded files as text/plain or using a separate user supplied content domain to prevent successful XSS from taking over the application.

V5.4 Memory, String, and Unmanaged Code

The following requirements will only apply when the application uses a systems language or unmanaged code.

# Description L1 L2 L3 CWE
5.4.1 Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows. ✓ ✓ 120
5.4.2 Verify that format strings do not take potentially hostile input, and are constant. ✓ ✓ 134
5.4.3 Verify that sign, range, and input validation techniques are used to prevent integer overflows. ✓ ✓ 190

V5.5 Deserialization Prevention

# Description L1 L2 L3 CWE
5.5.1 Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. (C5) ✓ ✓ ✓ 502
5.5.2 Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks. ✓ ✓ ✓ 611
5.5.3 Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers). ✓ ✓ ✓ 502
5.5.4 Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON. ✓ ✓ ✓ 95

References

For more information, see also:

For more information on auto-escaping, please see:

For more information on deserialization, please see: