WebApp Sec: Re: SQL Injection

[Stephen de Vries <stephen () corsaire com>]

On 9 Jun 2004, at 18:39, Steven M. Christey wrote:
< snip >
> So, I guess my point is that whitelists can't be used in isolation.
> Quoting and encoding must still play a role when passing inputs
> between data boundaries.  Sorry if this is old hat to everyone else.
That's a good point - Input validation should really be performed in 
every processing context, because it is only in that context that you 
know what is valid and what is invalid data.  If the same piece of 
input data is first used to query an SQL database, and then displayed 
back to the user in a browser, there should be two validation routines, 
the first performed by the SQL functions to validate and sanitize the 
input for SQL queries and the second by the functions that send the 
response to the browser which should again perform validation and 
sanitizing to make sure that no HTML elements are allowed.
In their simplest form validation routines only return a binary value, 
either the input data is valid, or it's not.  But if the validation is 
performed in the processing context it is possible to further classify 
invalid data so that the application can produce a more customized and 
appropriate response.  It may even be possible to distinguish between 
accidentally erroneous input and deliberate malicious input where the 
latter would cause the application to respond by invalidating the 
session, logging the connecting data and possible sending an alert to 
the IDS system.
A validation process could be:
1.  Define the set of valid data in terms of:
        1.1 Length
        1.2 Characters (e.g. [a-zA-Z]
         1.3 Optionally define data patterns e.g. ( 
[0-9]+[a-zA-Z]+[0-9]* )
2.  Optionally define data that constitutes an attack in this context 
e.g. in a search field: UNION%20SELECT
3.  Define the meta-characters that have special meaning in this 
processing context e.g. ' in SQL statements
4.  Transform the input data into canonical form
5.  Apply the validation rules from 1.
	5.1 If the data fails, apply the attack rules from 2 and take 
appropriate action.
6.  Apply the attack rules from 2.
7.  Transform the data by substituting the meta-characters defined in 3.
8.  Pass the data on to be processed.

2p

Stephen