WebApp Sec mailing list archives

Re: SQL Injection


From: Stephen de Vries <stephen () corsaire com>
Date: Fri, 11 Jun 2004 16:00:49 +0100


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


Current thread: