Skip to content

tainted_input.md

Latest commit

 

History

History
83 lines (69 loc) · 3.88 KB

tainted_input.md

File metadata and controls

83 lines (69 loc) · 3.88 KB

Tainted Input

General
  • Ensure input validation and output encoding have a common architecture to prevent injection attacks.
  • Verify that input data is strongly typed, validated, range or length checked, and sanitized or filtered.
  • Encode or escape output data for the context of the data as close to the output interpreter as possible.
Input Validation
  • Defend against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters.
  • Protect against mass parameter assignment attacks and against unsafe parameter assignment.
  • Validate all input using positive validation (whitelisting), including HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc.).
  • Strongly type structured data and validate against a defined schema including allowed characters, length and pattern.
  • Allow only whitelisted destinations for URL redirects and forwards, or warn when redirecting to potentially untrusted content.
Sanitization and Sandboxing
  • Properly sanitize:
    • All user input.
    • All untrusted HTML input from WYSIWYG editors or similar with a vetted library or framework feature.
    • Unstructured data and enforce safety measures such as allowed characters and length.
  • Avoid the use of dynamic code execution features (e.g. eval() ). When there is no alternative, sanitize or sandbox any user input being included before being executed.
  • Validate or sanitize untrusted data or HTTP file metadata, such as filenames and URL input fields.
  • Use whitelisting of protocols, domains, paths, and ports.
  • Sanitize, disable, or sandbox user-supplied:
    • SVG scriptable content.
    • Scripting or expression template language content (e.g. Markdown, CSS or XSL stylesheets, or BBCode).
Output Encoding
  • Use output encoding relevant for the interpreter and context required (e.g. for HTML values, HTML attributes, JavaScript, URL Parameters, HTTP headers, or SMTP).
  • Preserve the user's chosen character set and locale, such that any Unicode character point is valid and safely handled.
  • Use context-aware output escaping.
  • Use parameterized queries, ORMs, or entity frameworks for database queries.
    • Where parameterized queries cannot be used, use context-specific output encoding.
  • Protect against JavaScript and JSON injection attacks:
    • For eval
    • Remote JavaScript includes
    • CSP bypasses
    • DOM XSS
    • JavaScript expression evaluation
  • Protect against LDAP Injection.
  • Protect against OS command injection; use:
    • Parameterized OS queries for operating system calls
    • Contextual command line output encoding
  • Protect against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.
  • Protect against XPath injection or XML injection attacks
Unmanaged Code
  • Use memory-safe String functionality.
  • Use safe memory copy and pointer arithmetic functionality.
  • Handle format strings as constant.
  • Use sign, range, and input validation techniques to prevent integer overflows.
Deserialization Prevention
  • Encrypt and check the integrity of serialized objects.
  • Use the most restrictive configuration possible.
  • Disable unsafe features such as resolving external entities.
  • Avoid or protect deserialization of untrusted data in both custom code and third-party libraries (e.g. JSON, XML and YAML parsers).
  • Use JSON.parse to parse JSON in browsers or JavaScript-based backends.
  • Never use eval() to parse JSON.
Example security user stories
  • As a user, I want the application to validate all input and escape output to ensure my data is protected from injection attacks.