Share via

ASP.NET v4.0 Security Update and ISAPI Filters on IIS 6.0

  • Article

A security patch for ASP.NET v4.0 was released recently.  The details of the patch can be found at https://www.microsoft.com/technet/security/bulletin/ms10-070.mspx.

I really only have one thing to say in this blog post:  If you use an ISAPI Rewrite Filter on IIS 6.0 and you're application pool is using ASP.NET v4.0, then you should disable the ASP.NET extensionless URL feature.  The security patch unfortunately deletes that registry setting, so you will have to reset it after you install the patch.  The security patch deletes all registry values beneath HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0, and restores them to their default values.  The rest of this blog post provides more detail. 

The security patch also has an unfortunate side-effect on IIS 6.0 of moving the ASP.NET v4.0 ISAPI Filter (aspnet_filter.dll) to the bottom of the global (effects all web sites) ISAPI Filter list in IIS configuration.  This could break applications if they have an ISAPI Filter that needs to come after aspnet_filter.dll.  If you installed the patch and suddenly started seeing failures with "/eurl.axd/{GUID}" (where {GUID} is a hexadecimal number) in the URL, then this is the most likely cause.  You can try re-ordering your ISAPI Filters list, but if you're not using the ASP.NET extensionless URL feature on IIS 6.0 then you should disable it as described at https://blogs.msdn.com/b/tmarq/archive/2010/06/18/how-to-disable-the-asp-net-v4-0-extensionless-url-feature-on-iis-6-0.aspx.  That blog post also explains how the ASP.NET v4.0 Extensionless URL feature works on IIS 6.0.

To change the order of the ISAPI Filters on IIS 6.0, open IIS Manager, find the "Web Sites" folder in the navigation tree, right click that folder and select "Properties", and finally select the "ISAPI Filters" tab.  From here, you can select an ISAPI Filter in the list and click the "Move up" button to change the order.  The ASP.NET v4.0 filter is the one that appends "/eurl.axd/{GUID}" to URLs, and in the IIS Manager user interface it appears under the name "ASP.NET_4.0.30319.0".  For more details on ISAPI Filters, see https://msdn.microsoft.com/en-us/library/ms524610(VS.90).aspx.  Note that ISAPI Filters can also be installed at the web site level, so you might need to move your custom ISAPI Filter from the web site level (local) to the web sites level (global) in order to re-order it relative to the ASP.NET v4.0 Filter.

The ASP.NET ISAPI Filter (aspnet_filter.dll) appends "/eurl.axd/{GUID}" to extensionless URLs in order to direct URLs to the ASP.NET ISAPI Extension (aspnet_isapi.dll).  The ASP.NET ISAPI Extension then removes "/eurl.axd/{GUID}" from the URL.  The problems with "/eurl.axd/{GUID}" appearing in URLs occur when an ISAPI Rewrite Filter gets between the ASP.NET ISAPI Filter and the ASP.NET ISAPI Extension, and does something (modifies the URL) that makes it impossible for ASP.NET ISAPI Extension to restore the URL, and so "/eurl.axd/{GUID}" remains in the URL. 

The ASP.NET v4.0 Extensionless URL (EURL) feature does its work during the SF_NOTIFY_PREPROC_HEADERS notification on IIS 6.0.  For those of you having problems with the Ionic’s ISAPI Rewrite Filter, I looked at the Ionic's source code and understand why ASP.NET's EURL feature breaks.  Ionic's ISAPI Rewriter Filter used to do rewrite and redirect during SF_NOTIFY_PREPROC_HEADERS, but the latest sources do it during SF_NOTIFY_AUTH_COMPLETE, which happens later.  So an older version of the Ionic’s ISAPI Rewrite Filter would be compatible with the ASP.NET EURL feature as long as it's ISAPI Filter comes first in the ISAPI Filter list (so it can't get between the ASP.NET ISAPI Filter and the ASP.NET ISAPI Extension), and the new version of Ionic’s ISAPI Rewrite Filter is not compatible at all with the ASP.NET EURL feature, no matter how the ISAPI Filters are ordered, because Ionic's does work in SF_NOTIFY_AUTH_COMPLETEwhich always comes in between the ASP.NET ISAPI Filter and the ASP.NET ISAPI Extension.  Note that the ASP.NET ISAPI Filter (aspnet_filter.dll) does more than implement ASP.NET EURL, and by no means should you uninstall the ASP.NET ISAPI Filter.  All you should do is disable the ASP.NET extensionless URL feature.

Comments

  • Anonymous
    October 22, 2010
    just a note: i'm running ISAPI_Rewrite (version 2) from Helicon and the rewriting and the extensionless url's are both working for me. I should mention that the extensionless url's didn't work until I set the root of the website to use ASP.Net 4, it was not enough to set the specific app folder to ASP.Net 4. (so far so good in our development server, I didn't try our production server yet ;)

  • Anonymous
    October 28, 2010
    Right, v4.0 aspnet_filter.dll will not enable the extensionless URL feature unless ".axd" is script mapped at the web site level.  To register ASP.NET script maps you would typically use aspnet_regiis.exe -s W3SVC/N/ROOT, where N is the siteID of the site you want to change.  Backup your metabase before using tools like this.

  • Anonymous
    January 22, 2012
    Thomas,

  1.  What are the guidelines for configuring ASP.NET 4.0 routing on IIS 6 and in web.config after disabling the extensionless url feature?  Are there additional steps that need to be taken?  Will a wildcard mapping to aspnet_isapi.dll suffice?
  2.  What advice do you have for configuring ASP.NET 4.0 and IIS 6 to map .pdf files in a particular directory to ASP.NET? I appreciate your assistance and expertise in this matter.
  • Anonymous
    February 01, 2012
    Michael,
  1. If you need to disable aspnet_filter, then by all means do.  If you don't, just use it.  As an alternative, you can use a wildcard mapping.  You'll find more on how to do that by searching online.
  2. You could use ASP.NET's StaticFileHandler.  It is a pretty good handler that uses both kernel and output caching, and handles range requests.  I think it has some limitations over the IIS static file handler, but I don't recall anything important.  It has been a couple years since I worked on the ASP.NET team. Also, I'd try one of the sites below as a good place to post questions: http://stackoverflow.com/ - many participants http://forums.iis.net/ - official IIS forums http://forums.asp.net/ - official ASP.NET forums Thanks, Thomas