Many years ago, I saw Timothy Berners-Lee, father of the World Wide Web, speak at a conference. His message was that URLs users could decipher were a bad ideal; Web applications should employ URLs that are deliberately complex, black boxes for which only the Web server has a key. I dont recall the specific reasoning behind Berners-Lees position, but I believe he wanted to ensure that the programmer could control the user experience.
I can see a security reason for such a move as well: Apart from exposing the underlying logic of the Web application in a way that invites exploits like SQL injection, easily apprehended URLs facilitate attacks based on legal but malicious HTTP requests designed to break the server. Many exploits on many Web servers, but most often IIS, have been based on URLs that were technically legal but employed buffer overflows or similar techniques.
There are tools to prevent many of these attacks by constraining the types and parameters of requests made to the server. The most famous is Microsofts UrlScan, an add-on that almost every IIS administrator should be running. UrlScan is also part of the IIS Lockdown Tool. Microsoft recently issued a small improvement to UrlScan 2.5: It no longer needs to be installed as an upgrade over UrlScan 2.0 but employs its own installer.
UrlScan blocks requests such as very long URLs; attempts to run .exe files on the server (an old NIMDA trick); URLs with binary data in them; and use of multiply denormalized URLs (links such as http://%f0%80%80%af/, which must be decoded more than once). It can also log the requests. Ive been running UrlScan for a while, and every once in a while I check my logs to see the evil things people try to do to my servers. Sometimes I also find coding errors on my part, such as links I put in my own pages with illegal characters (such as using a "\" instead of a "/" in a link).
Even if they are unpatched, many of the most famous vulnerabilities in IIS can be rendered moot by the generic good-linking rules in UrlScan. For instance, you may remember a base Windows vulnerabiity that was originally reported in mid-March as an IIS hole. Since the original vector to this attack was through WebDAV, that specific vector itself remained an important vulnerability. I read reports (never confirmed or disproven) that UrlScan also prevented this specific attack because the WebDAV vector relied on a buffer overflow and therefore required very long URLs. And remember that these attack URLs can attack flaws not just in IIS but in your own applications.
Apache users have the mod_rewrite module, which can perform these tasks and a great deal more. Unfortunately, its a general-purpose programmable URL-manipulation package, not a canned security tool like UrlScan, and even the mod_rewrite author thinks its hard to use. There is a Rewrite Guide that has lots of help and more info on modrewrite.com. I expected to find a canned set of mod_rewrite rules to perform tasks like UrlScans, but I didnt. If someone knows of such a thing, let me know.
Why did Microsoft feel it necessary to keep UrlScan as a separate program? Partly because it can block requests that are technically legal, and it can block features (like the Server header) that some users consider an unnecessary exposure of system internals but on which some applications rely (such as Macromedias Cold Fusion in the Server Header case). But mostly its because UrlScan 1.0 came out after Windows 2000 was released, as one of many stopgap measures to plug the holes in that servers security.
Most of the hard lessons about Web server security that Microsoft learned, it learned after Windows 2000 came out. Windows 2003 Servers IIS Version 6 is a complete rewrite with security features generally far more powerful than those in UrlScan. There are a few features IIS 6 doesnt implement because the developers felt there was no benefit, so some administrators will still run it with Windows 2003.
Im curious to hear your impressions of UrlScan. From what Ive seen, Web sites that dont run it dont usually have a good reason not to, and they expose themselves to unnecessary attacks as a result. Why arent you running it? Let me know.
Security Supersite Editor Larry Seltzer has worked in and written about the computer industry since 1983.