RE: SQL Injection

["Michael Howard" <mikehow () microsoft com>]

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.

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. Sure, it
means a little more work for you, but it also means a heck of a lot more
work for the bad guys.

[Writing Secure Code 2nd Edition]
http://www.microsoft.com/mspress/books/5957.asp
[Protect Your PC] http://www.microsoft.com/protect
[Blog] http://blogs.msdn.com/michael_howard
[Annual Security Training]
http://mste/training/offerings.asp?offeringid=7142

-----Original Message-----
From: Steven M. Christey [mailto:coley () mitre org] 
Sent: Tuesday, June 08, 2004 2:52 PM
To: webappsec () securityfocus com
Subject: Re: SQL Injection


> BTW, any opinions on if I just encode all input without checking for
any
> characters? Say converting all <script> to &lt;script&gt; Can anyone
> still do XSS or SQL Injection in that case?

Not that I can think of, but there might be implications if there's a
back end.

However...  If the routine is being coded in C or another language
that's prone to buffer overflows, then you need to make sure to
account for all the potential quoting when allocating the memory to
hold the resulting string.  "Transformation-based" buffer overflows
(my hastily coined term) are starting to become more common.  If the
transformation converts a double-quote character to a "&quote;", then
an attacker could expand the original string by a factor of 6, which
could have implications for the application itself *or* the back end.

- Steve