mailing list archives
Re: SQL Injection
From: The Crocodile <tcroc () pasture com>
Date: Fri, 04 Jun 2004 08:24:32 -0400
I think I'm confused about your use of the term "whitelist" in the
scenario below. White lists IMHO aren't going to be vulnerability
specific at all. They are going to be specific to the particular input
parameter in question. I don't see how you would have differing
"whitelists" for XSS and for SQL Injection.
A white list is specifically what is going to be allowed for a
particular parameter. For example a phone number in the US might allow
1234567890()- and that's it. White listing the particular input field to
allow only those characters (and escape them if neccesary) should stop
both XSS and SQL injection attack characters. Encoding the output
presented to the user is an additional step that can be done to double
check for display type attacks (again XSS).
Maybe I misunderstood your post, but I just wanted to make sure these
subtle differences were clear to the list.
And yes I know "whitelisting" won't catch input data that is valid that
additional business logic should be catching. IE. Access control
violations. That is a different thread all together.
On Thu, 2004-06-03 at 20:35, Steven M. Christey wrote:
The best way would be creating a white list, allowing only defined
characters and rejecting everything else. Saves you headaches in the
long run. Use Regexs for this.
While white lists are far better than black lists, the correct "white
list" will vary depending on which type of vulnerability you are
protecting against. For example, restricting inputs to alphanumeric,
spaces, and hyphens will still open you up to certain argument
injection vulnerabilities. So, you may need to apply different white
lists to the data, depending on where (and how) the data is being
used, and which types of vulnerabilities may be present at that point.
You may want to use a "SQL injection" white list on data input, with
an "XSS white list" on data output (though "XSS white list" is almost
an oxymoron these days, with all the custom browser behaviors).
It would be interesting to know if anybody's tried to implement
"context-sensitive taint checks" that know which filters have been
applied to data elements, and when.