Transcript Chapter 5

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