Re: URLScan and SQL Injection

From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 03/02/04


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

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
hypothetical examples:

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" <cwyatt@rcn.com> wrote in message
news:5b7b562c.0403020325.1c475a99@posting.google.com...
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]" <someone@online.microsoft.com> wrote in message
news:<O#J2$no$DHA.2308@tk2msftngp13.phx.gbl>...
> 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" <cwyatt@rcn.com> wrote in message
> news:5b7b562c.0402270334.3d0040f2@posting.google.com...
> "David Wang [Msft]" <someone@online.microsoft.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


Relevant Pages

  • Re: Adding name-value pair to QueryString Collection?
    ... in the page load event, would check if the formSessionId variable is set ... to the server. ... Basically what I want to do is check the QueryString in the Load event ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: XMLHttpRequest: POST with Data
    ... .QueryString contains the contents of the GET query string, ... not the form POST. ... unescapeat server. ... Are escape() and unescapethe correct functions to use? ...
    (comp.lang.javascript)
  • Re: Understanding query strings
    ... >a gridview that shows details about that server. ... > What I would like to do is add the ability to pass a querystring to the ... > ability to change the server name once I get to the page if I need to. ...
    (microsoft.public.dotnet.framework.aspnet.webcontrols)
  • Re: XMLHttpRequest: POST with Data
    ... If you send a POST request, ... query string will be sent (so .QueryString, which is supposedly .NET, ... Going to the server, any ... Are escape() and unescapethe correct functions to use? ...
    (comp.lang.javascript)