mailing list archives
RE: SQL Injection
From: "Michael Howard" <mikehow () microsoft com>
Date: Tue, 8 Jun 2004 22:59:59 -0700
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
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]
[Protect Your PC] http://www.microsoft.com/protect
[Annual Security Training]
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
characters? Say converting all <script> to <script> 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
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 ""e;", 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.