Re: SQL Injection

[Frank Knobbe <frank () knobbe us>]

On Fri, 2004-06-11 at 10:00, Stephen de Vries wrote:
> > 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.


Actually, I don't think this can't be considered input validation
anymore. I have been using the phrase "output validation" or "output
conversion" in my reviews. We've always been preaching both sides of
data handling, input and output, but I seldom see output addressed in
public forums (makes it harder to convince clients, but test results
usually speak for themselves :).

Data should be properly validated and/or converted for use in a safe
format. This is highly depending on your use of data. For this example,
let's just use a scenario where you want to avoid single-quotes, but
could allow double-quotes. Your input validation routines check and
convert it (either encoded, escaped, or substituted). Now the data is
safe for handling in database routines.

However, that same data is not safe for output to a web browser since it
allows double-quotes (nice XSS if that data is printed in a form field
for example). So here we have the scenario were the data needs to be
validated/converted before being sent to the browser. 

But since this is at output time, why not call it output validation? 

The easiest way would be to just HTMLEncode the data before printing to
the browser. That ensures that all, including potentially dangerous
characters like the brackets and double-quotes, are properly formatted
and do not cause issues in the browser (prematurely terminating tags or
form fields, or including tags to allow scripting). If of course you
require certain HTML behavior (such as text styles -- bold etc), then
your output validation/conversion routines have to be customized.

But the basic fact is that you have TWO checkpoints. Checking data on
input and checking data on output.

I hereby propose to add this category (Output Validation) to the OWASP
guides and Top 10 list. I believe that Output Validation should be on
number one, followed by input validation. There are a lot of web sites
that are trying to tackle input validation, but have not at all
considered output validation (and are thus vulnerable).

Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part