Re: SQL Injection

[The Crocodile <tcroc () pasture com>]

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.

Cheers,

--The Crocodile

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