COVER YOUR SECURITY HOLES! It's quick, it's painless, and should be a standard procedure for all production apps.

On with the blog.

I was reading my daily email and ran accross a new alert. Apparantly on 10/6/2004 Microsoft released KB Article 887459. This article can be read here http://support.microsoft.com/default.aspx?scid=kb;EN-US;887459  The site that I visit to find out about these is http://kbalertz.com. Great site, they have a free email letter. Sign up if you're any kind of a respectable Microsoft geek.

So, in this website, on the feedback someone says, “Well, we have URLScan installed. Aren't we already covered“

Yes, my friend, you are covered from a canononical attack if you use the default install of URLScan, and it hasn't been tampered with, and you can ensure some sysadmin hasn't uninstalled it, or some developer who is too lazy to write code that is kosher with that kind of tool. Lets not forget, gasp, our customers may not have this installed.

If you read the documentation for URLScan here  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/HT_URLScan.asp You'll find the following info

• URLScan blocks requests that contain potentially harmful characters, for example, characters that have been used to exploit vulnerabilities in the past such as "." used for directory traversal. It is not recommended that project paths contain the "." character. If you must allow this, you need to set AllowDotInPath=1 in URLScan.ini. 

It's very clear that URLScan does do the same 'thing' (blocking a period to avoid canononical traversal) only in the sense that it accomplishes it as an end result. It does not do provide a total solution for all vectors of attack. The problem is that if you deploy a webapp to a customer's box, you cannot ensure that they have (or will have) Urlscan installed. If you the vendor do not take steps to make sure that kind of functionality is provided within the app, you're going to loose one (if not many more) customers. This kind of common sense is not something they put in KB articles, and is reserved mostly for blogs. Sigh. Maybe someone will read this and take it to heart.

Update,

I pulled this information from Scott Hanselman's blog http://www.hanselman.com/blog/PermaLink.aspx?guid=78159d3b-40f2-45d0-93ad-2718274cbccb

1) Updated http://www.microsoft.com/security/incident/aspnet.mspx with new information about the reported vulnerability.  This should help clear up some of the confusion we've seen about what is affected by this.  To be super clear, all ASP.NET applications, on ALL OS's should follow the guidance provided.

2) A new HTTP Module mitigation best practice.  This is in the form of an MSI installer that will help protect all ASP.NET applications on a Web server.  This MSI installer will place a binary into the GAC and update the machine.config file for ASP.NET.  You can find download information at http://www.microsoft.com/downloads/details.aspx?FamilyID=da77b852-dfa0-4631-aaf9-8bcc6c743026&displaylang=en

You can also download the MSI directly at http://download.microsoft.com/download/4/6/1/461433d5-cbac-4721-85cb-c5a514fd0049/VPModule.msi

3) Detailed guidance about the HTTP Module, how the MSI works, and how to deploy it.  You can find this KB Article at http://support.microsoft.com/?kbid=887289