Avoiding Integrated pipeline authentication for 404 requests for static files

Question

I have a site running in Integrated mode on IIS7 and have changed the web.config so the static files are authenticated. What I would like to fix is when a request for a not existing file comes in, it still goes through the .NET authentication pipeline, I see by debugging Begin_Request() method that the request is made for /login.aspx?returnurl=filenotfound.js (paraphrasing here).

Has anyone got any tips on how to catch and return the 404 before the authentication kicks in?

Thanks

Answer 1

My main bit of advice would be; don't.

If you require authentication on certain resources, then you've presumably got something to hide. When you've got something to hide, you should pay attention to what you are revealing, and when you are giving a different response for a resource that has a file for it and one that doesn't you are revealing something.

Is this a major security hole? I can't say, but it could be enough to reveal something to an attacker. It's certainly and enlargement of the attack surface, so you've got two options.

1. Do painstaking analysis to prove that the information on which URIs are mapped to files and which aren't is of no benefit to an attacker.
2. Require authentication for the request even though all it will give an authenticated user is a 404.

The latter is easier and less error prone.

That said, there's a few ways to do authentication in ASP.NET with integrated mode. Are you doing it in modules that handle the AuthorizeRequest and AuthenticateRequest events? You could have them check whether such a case is occurring (check whether the URI maps to an existing file or not) and not send a 401 if that's the case.

Answer 2

You could possibly map 404s to an *.aspx page at the application level. Thus, all requests to nonexisting resources will be remapped to the page and the querystring parameter will indicate the name of the nonexisting resource. Assuming that the page could be excluded from the authorization engine (available to everyone), you could put the precise logic handling different cases to the page.

    <httpErrors errorMode="Custom">
        <remove statusCode="404" subStatusCode="-1"/>
        <error statusCode="404" prefixLanguageFilePath="" path="/ErrorHandler.aspx" responseMode="ExecuteURL"/>
    </httpErrors>

With this, all 404s are routed to ErrorHandler.aspx?404;theurlofnonexistingresource.