Browsing to .../trace.axd shows server information - PCI show stopper

Question

My company runs PCI compliance scans and one that dings us every time is that ASP.NET Detailed Error Message Information Leak.

The description is: A detailed ASP.NET error message was discovered... and it's worried that we are showing potential hackers our ASP.NET version, IIS version, etc.

The thing that triggers this information is browsing to "oursite"/Trace.axd and if you do you get a Trace Error message like this:

Trace Error Description: The current trace settings prevent trace.axd from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

which has this at the bottom of the page:

-------------------------------------------------------------------------------- Version Information: Microsoft .NET Framework Version:2.0.50727.4234; ASP.NET Version:2.0.50727.4223

The funny thing is that the error message is saying how trace is disabled and you have to change web.config to see it! My web.config has (exerpt):

<configuration>
  <system.web>
    <trace enabled="false" requestLimit="10" pageOutput="false" localOnly="true" />

I believe this is the right hierarchy for the trace disable statement. I don't understand why the server is responding with a message saying trace is disabled if it is disabled. If this is normal behavior then why is our PCI scanner complaining about divulging too much info?

Any help making it stop being so talkative is greatly appreciated.

BTW, if it matters, my Custom Errors is like this:

<system.web>
    <customErrors mode="Off" defaultRedirect="~/Errors/GeneralError.aspx">
        <error statusCode="404" redirect="~/Errors/PageNotFound.aspx" />
    </customErrors>

Answer 1

First, make sure CustomErrors are on by using:

<customErrors mode="On" 

or even

<customErrors mode="RemoteOnly"

As for the trace.axd, your web.config is correct and having trace enabled="false" should keep that URL from being navigable. I believe it was only showing that error information because your custom error pages weren't being used.

Answer 2

None of these solutions worked for us because the handler is registered and bypasses the MVC pipeline. Our solution was to remove the handler before the mvc handlers are registered.

<system.webServer>
    <handlers>    
        <remove name="TraceHandler-Integrated" />
        <remove name="TraceHandler-Integrated-4.0" />

Worked like a charm and returned a 404 when requested.