How to remove WebResource.axd and ScriptResource.axd from MVC application RRS feed

  • Question

  • User1609621261 posted

    So I've been working on simply getting WebResource.axd and ScriptResource.axd removed from my applications, since I see absolutely no point in them, other than granting hackers a backdoor to my applications. I have an application that requires the user to login in order access anything in it, except the stylesheet and login screen. If i try to access any part of the website, I get thrown right back to the login screen, however if I type in {app}/WebResource.axd or {app}/ScriptResource.axd, it get a 404 back from the server. This is not supposed to happen, I'm supposed to get thrown back to the login screen.

    So I added the following to all my web.config files

                <remove path="WebResource.axd" verb="GET"/>
                <remove path="WebResource.axd" verb="POST"/>
                <remove path="ScriptResource.axd" verb="GET"/>
                <remove path="ScriptResource.axd" verb="POST"/>

    Now when I try to request the WebResource.axd, I get the login screen as expected. However, when I request the ScriptResource.axd I still get the 404 page.

    Is this the correct way to remove WebResource.axd completely from my application? And how do I get rid of ScriptResource.axd?

    Finally, are there any other hidden objects in ASP.Net that users can request that I need to know about? And how do I block them? Isn't there an easy way to block everything, except the things I have given permission to???

    Monday, September 20, 2010 1:10 PM

All replies

  • User-619846739 posted

     If you're using Integrated Pipeline mode (assuming IIS7.x) you need to remove them from <handers> in <system.webServer> instead.

    Alternately, you can use URL Rewrite (assuming IIS7.x too) and block those.

    If you go to the <httpHandlers> section of your root web.config (c:\windows\microsoft.net...), you'll see all possible configs.  trace.axd looks like another possible candidate.

    Monday, September 20, 2010 3:41 PM
  • User1459398585 posted


          <remove name="AssemblyResourceLoader-Integrated" />
          <remove name="AssemblyResourceLoader-Integrated-4.0" />
          <remove name="ScriptResourceIntegrated-4.0" />

    Tuesday, September 21, 2010 1:42 PM
  • User1311437028 posted

    This is an excellent question, and I think it's something I'd like to see some guidance on from Microsoft. Looking thru the handler mappings configured for my local IIS server, I have to wonder how many of those are really needed. Of the ones that have a path similar to WebResource.axd, there is ScriptResource, trace, WebAdmin and _AppService.axd.

    Now maybe there is nothing wrong with some of the handlers listed, but why take the chance. Default should be not mapped or at least disabled by default.

    Tuesday, September 21, 2010 2:15 PM
  • User1459398585 posted

    I think that WebResource and ScriptResource are the only ones that you need to worry about. I may be wrong on that, but I think that they are the only two that check an ecrypted string, and if it's right, return a file.

    This is how they get your web.config (I send it an encrypted string that says give it to me, and if my string is right, it does). The attack vector I've seen is to essentially as WebResource / ScriptResource for a file that is definitely not going to exist (Like IDontExist.aspx). If the string is right, I'll get a 404 error. If it's wrong, I get a 500.

    I disabled these two handlers just for this security vulnerability, but I don't think it's necessary to disable all of them (Especially since I don't really know off hand what the rest do!).

    / Michael /

    Tuesday, September 21, 2010 3:49 PM
  • User1609621261 posted

    The application is hosted with several of our customers, some on IIS 6 and some on IIS 7.

    I've tried removing handlers and httphandlers, and ScriptResource.axd still behaves differently than what is supposed to be the default behaviour. All of the other files don't seem to respond to any requests, and my application behaves as expected when I type them in the url.

    I even tried adding the following

    <location path="ScriptResource.axd">
                    <deny users="*"/>

    But no matter how I try to configure my application, ScriptResource.axd always seems to behave differently than expected.

    Wednesday, September 22, 2010 6:28 AM