mailing list archives
Re: SQL Injection
From: "Steven M. Christey" <coley () mitre org>
Date: Wed, 9 Jun 2004 13:39:39 -0400 (EDT)
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
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
- 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.
Re: SQL Injection Steven M. Christey (Jun 11)
Re: SQL Injection Frank Knobbe (Jun 16)
Re: SQL Injection Jeff Williams (Jun 17)
Re: SQL Injection Frank Knobbe (Jun 17)
Re: SQL Injection Frank Knobbe (Jun 29)
RE: SQL Injection Mutallip Ablimit (Jun 29)
- Re: encryption over the web, (continued)