Re: SQL Injection

["Jeff Williams" <jeff.williams () aspectsecurity com>]

> 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).

Output validation is intended to protect against attempts to inject attacks
into the browser. The most important of these is cross-site scripting, which
is covered by the Top Ten A4, and HTML entity encoding is suggested there.

I believe it is frequently possible to validate input in such a way that it
is safe both for the database and for rendering in a browser. If you have a
special need for storing unencoded data in the database, then adding some
output encoding makes sense.

I'm really glad to see a discussion of what belongs in the Top 10.  The T10
are not intended to be in order of importance,  although validation is
certainly a key issue.  I can't see how output validation (assuming that
input validation is done properly and XSS attacks are also handled) rates a
separate slot in the Top 10. What would you remove?

--Jeff

Jeff Williams
Aspect Security, Inc.
http://www.aspectsecurity.com

----- Original Message ----- 
From: "Frank Knobbe" <frank () knobbe us>
To: <webappsec () securityfocus com>
Cc: <mark () curphey com>; "Stephen de Vries" <stephen () corsaire com>
Sent: Tuesday, June 15, 2004 4:09 PM
Subject: Re: SQL Injection


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.
Regards,
Frank