Input and Data Validation

From Guidance Share

Jump to: navigation, search

Contents

Description

Input and data validation is a key category for potential security issues. If an attacker discovers that your application makes unfounded assumptions about the type, length, format, or range of input data. The attacker can then supply carefully crafted input that compromises your application.

When network and host level entry points are protected; the public interfaces exposed by your application become the primary source of attack. The input to your application is a means to both test your system and a way to execute code on an attacker's behalf. Does your application blindly trust input? If it does, your application may be vulnerable.

Vulnerabilities

  • Use of unsafe functions (in unmanaged code)
  • Ineffective or lacking encoding on untrusted input
  • Integer assignment or integer operations being carried out without validating the untrusted input
  • Building dynamic LDAP queries using untrusted input
  • Ineffective or lacking confirmation of user's actions
  • HTTP Response headers populated with untrusted input
  • Allowing users to upload script or executable files in the webroot (e.g., .asp pages, .exe, etc.)
  • Use of dynamic SQL
  • Inappropriate or lacking schema validation
  • Allowing an untrusted source to specify the name of a file resource
  • Allowing an untrusted source to manipulate the format string (e.g., format string in printf())
  • Lacking or ineffective performance considerations (e.g., indices on data tables, using string instead of StringBuilder to build dynamic strings, etc.)


Attacks

  • Buffer Overflow Attack
  • Canonicalization
  • Cookie Manipulation
  • Cross Site Scripting Attack
  • Denial of Service
  • Form Field Manipulation
  • Format-String Attack
  • HTTP Header Manipulation
  • LDAP Injection
  • Integer Overflows/Underflows
  • One-Click Attack
  • Response Splitting
  • Server-side Code Injection
  • SQL Injection Attack
  • Query String Manipulation
  • XML Injection


Countermeasures

  • Use safe functions such as strncpy, strncat instead of strcpy, strcat
  • Perform context sensitive encoding of untrusted input before it is echoed back to a browser by using an encoding library
  • Utilize platform checks for integer overflow/underflow (e.g., CheckForOverflowUnderflow in C#, RemoveIntegerChecks in VB.NET)
  • Untrusted input should be validated against an inclusion list before use (e.g., RegEx pattern, primitive type casting, domain constraint, etc.)
  • Utilize human interactive proofs (HIPs) to confirm the action of an authenticated principle
  • Perform context-sensitive encoding of input before using it in in HTTP headers (e.g., IOSec)
  • Scan uploaded files for viruses
  • Use parameterized SQL statement
  • Validate schema against a defined XSD
  • Only accept primitive typed identified (e.g., integers) which are mapped to filenames
  • Hardcode the format string
  • Performance should be considered a requirement especially for areas of the application where availability of the service is essential


Done

Personal tools