Home page logo
/

webappsec logo WebApp Sec 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
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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]