V5 - reorganize input validation, sanitze and encoding subcategories

[elarlang]

As #449 it ended up a bit different way like intended and expected and this is have not been re-opened, I create new separate issue to address this idea/problem.

My idea was to separate Input sanitize and output encoding requirements. At the moment requirements in V5 subcategories really don't mach with subcategory title.

My proposal (reasons and discussion can be found in #449):

Input validation

• 5.1.1 Verify that input validation is enforced on the server-side.
• 5.1.2 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).
• 5.1.3 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.
• 5.1.5 Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (whitelisting).
• 5.1.6 Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match).
• 5.1.7 Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length, and characters potentially harmful in given context should be escaped (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara).

sanitize and sandbox

• 5.1.4 Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature.
• 5.2.7 Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.
• 5.2.8 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.
• 5.2.9 Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.
• 5.2.10 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, use whitelisting of protocols, domains, paths and ports.
• 5.2.11 Verify that the application sanitizes, disables, or sandboxes user-supplied SVG scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.
• 5.2.12 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.

Output encoding and Injection Prevention Requirements

• 5.3.1 Verify that output encoding occurs close to or by the interpreter for which it is intended.
• 5.3.2 Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, URL Parameters, HTTP headers, SMTP, and others as the context requires.
• 5.3.3 Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled.
• 5.3.4 Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS.
• 5.3.5 Verify that any user-supplied data included in the browser's DOM or web views protects against JavaScript code execution and XSS attacks.
• 5.2.6 Verify that where potentially untrusted data is copied one DOM context to another, the transfer uses safe JavaScript methods, such as using innerText or JQuery .val to ensure the application is not susceptible to DOM Cross-Site Scripting (XSS) attacks.
• 5.3.6 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.
• 5.2.1 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.
• 5.2.2 Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have been implemented.
• 5.2.3 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.
• 5.2.4 Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.
• 5.2.5 Verify that the application protects against XPath injection or XML injection attacks.

[vanderaj]

Done