Home page logo

webappsec logo WebApp Sec 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
[Blog] http://blogs.msdn.com/michael_howard
[Annual Security Training]

-----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
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

  By Date           By Thread  

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