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:
- Re: encryption over the web, (continued)
- Re: encryption over the web Keith W. McCammon (Jun 14)
- Re: encryption over the web Ivan Krstic (Jun 14)
- Re: encryption over the web Paul Johnston (Jun 14)
- Re: encryption over the web Pawel Jablonski (Jun 14)
- Re: encryption over the web Frank Knobbe (Jun 16)
- RE: encryption over the web Fan Zhang (Jun 16)
- Re: encryption over the web Lucas Holt (Jun 16)
- Re: encryption over the web Michael Ströder (Jun 17)
- Re: encryption over the web exon (Jun 17)
- Re: SQL Injection Stephen de Vries (Jun 11)
- Re: SQL Injection Rogan Dawes (Jun 14)
- Re: SQL Injection David Cameron (Jun 16)
- Re: SQL Injection Sverre H. Huseby (Jun 16)
- Re: SQL Injection Alex Russell (Jun 17)