9. October 2008 17:15
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.0is 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
"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:
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
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.
6. October 2008 04:58
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:
After analyzing this URL we determined few optional strings to block. Here are some of them:
- "declare @s 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!
4. October 2008 04:26
My materials (PPTs etc) from Bleeding Edge are now available for download.