R173. Discard unsafe inputs

Requirement

The system must discard all potentially harmful information received via data inputs.

Description

Technological devices and, in particular, applications must be able to notice if the received information that does not correspond to its operational purposes, in order to treat it properly (for example, rejecting and/or generating timely alerts) and so that it does not impact the operation negatively. Typical examples of this are: SQL queries, JavaScript code, OS commands or LDAP queries in fields and application parameters; text with undesired special characters and their possible combinations in fields and parameters; files manipulated in structure and extension to be loaded in an application or technology artifact, and in general any type of information that does not correspond to the requested format. A large amount of the incoming traffic (which does not correspond to operational purposes) of a technological artifact must also be considered and controls and proper treatment must be applied.

Implementation

  1. Perform whitelisting instead of blacklisting: By using this principle, the control implementation will be configured to reject all inputs that are not explicitly approved discarding all possible scenarios and forcing enumeration of strictly allowed inputs. E.g. allow only a-z, A-Z y 0-9.

  2. Use variable highlight: If supported, language and compiler can detect foreign variables that are not validated by a filter. To this end, you may use techniques to highlight those variables and compilers or pre-processors to detect that they are not validated.

  3. No only user validation but also input validation: Any input from outside the application must be considered malicious, that is to say, the user can enter incorrect information as well as potentially harmful inputs that may also compromise external systems, therefore this information must be validated.

Attacks

  1. Inject malicious software or code.

  2. Denial of service caused by register overload.

  3. Cross-Site Scripting (XSS).

  4. OS command injection.

  5. SQL injection.

  6. LDAP injection.

  7. Redirect to untrusted pages.

Attributes

  • Layer: Application Layer

  • Asset: Source code

  • Scope: Maturity

  • Phase: Building

  • Type of Control: Recommendation

References

  1. A1 Injection OWASP - Top 10 2013

  2. A3 Cross-site Scripting (XSS) OWASP - TOP 10 2013.

  3. A10 Unvalidated Redirects and Forwards OWASP - TOP 10 2013.

  4. CWE-20: Improper Input Validation. The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.

  5. CWE-74: Injection. The software constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements.

  6. CWE-78: OS Command Injection. The software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command.

  7. ​CWE-79: Cross-site Scripting. The software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

  8. CWE-80: Basic XSS. The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters such as "<", ">", and "&" that could be interpreted as web-scripting elements.

  9. CWE-89: SQL Injection. The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command.

  10. CWE-94: Code Injection. The software constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

  11. CWE-116: Improper Encoding or Escaping of Output. The software prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.

  12. CWE-138: Improper Neutralization of Special Elements. The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.

  13. CWE-147: Improper Neutralization of Input Terminators. The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as input terminators when they are sent to a downstream component.

  14. CWE-159: Improper Handling of Invalid Use of Special Elements. The product does not properly filter, remove, quote, or otherwise manage the invalid use of special elements in user-controlled input, which could cause adverse effect on its behavior and integrity.

  15. CWE-602: Client-Side Enforcement of Server-Side Security. The software is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.

  16. CWE-643: XPath Injection. The software uses external input to dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input.

  17. CWE-943: Improper Neutralization of Special Elements in Data Query Logic. The application generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query.

  18. OWASP-ASVS v4.0.1 V1.5 Input and Output Architectural Requirements.(1.5.3) Verify that input validation is enforced on a trusted service layer.

  19. OWASP-ASVS v4.0.1 V1.5 Input and Output Architectural Requirements.(1.5.4) Verify that output encoding occurs close to or by the interpreter for which it is intended.

  20. OWASP-ASVS v4.0.1 V5.1 Input Validation Requirements.(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).

  21. OWASP-ASVS v4.0.1 V5.1 Input Validation Requirements.(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 (whitelisting).

  22. OWASP-ASVS v4.0.1 V5.1 Input Validation Requirements.(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 or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match).

  23. OWASP-ASVS v4.0.1 V5.2 Sanitization and Sandboxing Requirements.(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.

  24. OWASP-ASVS v4.0.1 V5.2 Sanitization and Sandboxing Requirements.(5.2.2) Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.

  25. OWASP-ASVS v4.0.1 V5.2 Sanitization and Sandboxing Requirements.(5.2.3) Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.

  26. OWASP-ASVS v4.0.1 V5.2 Sanitization and Sandboxing Requirements.(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.

  27. OWASP-ASVS v4.0.1 V5.2 Sanitization and Sandboxing Requirements.(5.2.5) Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.

  28. OWASP-ASVS v4.0.1 V5.2 Sanitization and Sandboxing Requirements.(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, or using whitelisting of protocols, domains, paths and ports.

  29. OWASP-ASVS v4.0.1 V5.2 Sanitization and Sandboxing Requirements.(5.2.7) 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.

  30. OWASP-ASVS v4.0.1 V5.2 Sanitization and Sandboxing Requirements.(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.

  31. [[31]] OWASP-ASVS v4.0.1 V5.3 Output encoding and Injection Prevention Requirements.(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.

  32. OWASP-ASVS v4.0.1 V5.3 Output encoding and Injection Prevention Requirements.(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.

  33. OWASP-ASVS v4.0.1 V5.3 Output encoding and Injection Prevention Requirements.(5.3.7) Verify that the application protects against LDAP Injection vulnerabilities, or that specific security controls to prevent LDAP Injection have been implemented.

  34. OWASP-ASVS v4.0.1 V5.3 Output encoding and Injection Prevention Requirements.(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.

  35. OWASP-ASVS v4.0.1 V5.3 Output encoding and Injection Prevention Requirements.(5.3.9) Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.

  36. OWASP-ASVS v4.0.1 V5.3 Output encoding and Injection Prevention Requirements.(5.3.10) Verify that the application protects against XPath injection or XML injection attacks.

  37. OWASP-ASVS v4.0.1 V5.4 Memory, String, and Unmanaged Code Requirements.(5.4.2) Verify that format strings do not take potentially hostile input, and are constant.

  38. OWASP-ASVS v4.0.1 V5.4 Memory, String, and Unmanaged Code Requirements.(5.4.3) Verify that sign, range, and input validation techniques are used to prevent integer overflows.

  39. OWASP-ASVS v4.0.1 V5.5 Deserialization Prevention Requirements.(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 XXE.

  40. OWASP-ASVS v4.0.1 V7.3 Log Protection Requirements.(7.3.1) Verify that the application appropriately encodes user-supplied data to prevent log injection.

Copyright © 2020 Fluid Attacks, We hack your software. All rights reserved.

Service status - Terms of Use - Privacy Policy - Cookie Policy