Chapter 5 Handling Input

VALIDATE! Validate all input Validate input from ALL sources Establish trust boundaries: store validated and unvalidated data separately to ensure that validation is always performed.

How to validate Use strong validation Avoid blacklisting Don't mistake validation for usability with validation for security. Reject bad data. Make good input validation the default. Use abstraction. Always check input length. Bound numeric input. (Above and below).

What to validate VALIDATE ALL INPUT Examples: Command line parameters, config files, data retrieved from a database, environment variables, Network services, registry values, system properties, temporary files, etc. Attack surface of an application (places where it accepts input) = set of function calls that are invoked externally or provide external data. Examples: cin, int main(args...)‏ Two kinds of validation: Syntax checking Semantic Checking

Some bad examples .htaccess file in Apache (page 123)‏ --delimiter parameter (page 124)‏

Database Queries Hard to check accuracy of database data. However sanity checks are a definite must: If the output is expected to be unique, check for only one row of data. Check the format of the data returned from the database: bad data could be the result of a misformed query or worse! Other, ad-hoc checks could be made.

Network Services DO NOT TRUST DNS NAMES DO NOT TRUST IP ADDRESSES DNS CACHE POISONING has happened and will happen again. Problem can happen for both outgoing and ingoing communications. Cautionary tales: Apple OS X (page 129) Sony Rootkit eraser

Establish Trust Boundaries Beware of mixing validated and unvalidated data; very easy to do sometimes. For example, sometimes all the data has to be read before it can be validated For example, a complex data structure is read and is hard to validate.

How to Validate Check input length (min and max)‏ Bound numeric values (min and max)‏ Whitelist: have a list of acceptable inputs to check against. Indirect Selection: index into a list of acceptable inputs. Whitelist: check the format (e.g. Phone numbers) Use regex? Avoid blacklisting. Beware of doubledecoding. Don't mistake usability for security. Reject bad data. Create a security-enhanced input API. Consistent – maintainable – constant – omnipresent

Metacharacter Vulnerabilities Metacharacters (' ; .. / \ && \n ...) are very dangerous. Use parameterized commands. Example: instead of SQL(...) use Select(<from>,<var>,<value>) for Select * FROM <from> WHERE <var> = '<value>' Beware of Path manipulation Command separation/injection Log Forging