Re: SQL Injection

["Steven M. Christey" <coley () mitre org>]

Michael Howard said:

> Simply escaping bad things is almost always the wrong thing to do when
> done alone. There may be ways to represent <script> (etc.) that are
> valid but you don't detect. And there may be way to represent script
> blocks without a script tag.
> http://www.securityfocus.com/archive/1/272037 lists some of these
> constructs.

An excellent point that I should have remembered before sending my
last response.  Thank you (and others) for correcting my error.

> The *only* really safe way to do this is to look for valid input
> requests, and reject them if they are not what you expect.

I think we still get back to the "vulnerability-aware whitelist"
challenge here, though.  If your data field is for a user name, then
"Jim O'Brien" may be an acceptable response (as Vladimir Poddubniy
suggested), which means that single quotes and spaces are valid for
the field.  Thus your whitelist would leave you open to a SQL
injection attack if you don't quote the characters.  It seems like
we're missing an important insight here, or maybe I'm just confused.

For example, the "Person's name" regular expression on the web site
you mentioned, allows these inputs:

  INPUT' AND Y

    - SQL injection, at least malformed; the "'" is sensitive

  ARG  -switch

    - possible argument injection (needs 2 spaces); the "-" is sensitive


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.

- Steve