Re: URLScan and SQL Injection
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: Tue, 2 Mar 2004 14:28:17 -0800
As Jeff and I have been arguing all along:
- You cannot use a generic tool, without context of what it is blocking, to
do what you are asking for.
- You have to implement the logic at the application layer. In your case,
you illustrate that CF, at tha application level, can enforce and validate
the record ID. This is EXACTLY the way to attack this problem. The WRONG
WAY to attack this problem is for a generic tool to filter for this record
Regarding your question about how to pass a SQL statement to a web page if
the server is disallowing key words -- I cannot answer the question until
you define how the web server is disallowing key words. I will give some
For example, suppose the server is doing a simply stricmp() against the
querystring to detect the disallowed keywords. To get around it, I would
simply URLEncode the disallowed keywoard to make them %-encoded, send that
as the value in the querystring, and then the recipient app will simply
URLDecode that value to get back the query.
Now, what you are trying to protect, with all the keyword denying, is that
recipient app -- how is the server supposed to know that the recipient app
will URLDecode the querystring, so that it can URLDecode the querystring to
detect the disallowed keywords? It cannot -- without special hardcoded
knowledge. Further suppose that you have 200 different apps, each with a
different variation of how they interpret the querystring -- how is a
generic tool supposed to obtain so much hardcoded knowledge and protect them
all? It cannot.
And where does your "CF method" fit into the picture? It fits in where the
recipient app will verify the querystring it obtains for correctness prior
to execution... which is exactly how you protect the recipient app -- by
rewriting it to be resiliant to attacks.
-- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // "Chuck Wyatt" <email@example.com> wrote in message news:firstname.lastname@example.org... Okay, so given what you say here (below), how could one pass a SQL statement to a web page (mine is ColdFusion) if the web server is disallowing key words as SELECT, DELETE, UPDATE, DROP? BTW, I could also disallow them in the post method, but obviously some major drawbacks for doing that. Incidentally, the CF method of doing this (X hundreds on my site), would be to make the query disallow the record ID as being anything but an integer. That way you can't "append" anything. -Chuck "David Wang [Msft]" <email@example.com> wrote in message news:<O#J2$no$DHA.firstname.lastname@example.org>... > You are ASSUMING that a hacker attack would actually "follow the rules". > > It is perfectly legal for software to use POST to retrieve form-entity data > that is posted and also to look at QueryString for more options. It is > perfectly legal for software to use GET for the exact same purpose. The > QueryString is ALWAYS opaque data for the application and impossible to > filter 100% correctly. > > In other words -- what SecureIIS offers in this feature is not bullet-proof > and is practically useless for all the prior reasons that I had mentioned. > > In the long term, you will be better served by writing secure code instead > of hoping to "snap on" security that partially alleviates your problem. > Security is a state of constant mindful configuration and not a product to > be "snapped on" and forgotten. > > -- > //David > IIS > This posting is provided "AS IS" with no warranties, and confers no rights. > // > "Chuck Wyatt" <email@example.com> wrote in message > news:firstname.lastname@example.org... > "David Wang [Msft]" <email@example.com> wrote in message > news:<eRHPvqL$DHA.268@TK2MSFTNGP10.phx.gbl>... > > For example, suppose you use a web > > mail package that passes the email title around in the querystring -- with > > your filtering, legitimate emails with "select" and "update" in them will > be > > rejected. > > Isn't it the case that the email would be processed using POST, while > with the SQL injection hacking, we are primarily concerned with GET > (query strings) ? My assumption, though I could be wrong here, is > that SecureIIS is blocking the passing of these keywords in the query > string (GET) rather than POST. > > thanks, > > Chuck