3

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>
Deverill
  • 971
  • 2
  • 17
  • 32
  • Shouldn't ` – MikeSmithDev Feb 03 '14 at 18:45
  • Yes, of course. That's the biggest part - it no longer shows the details. Is there a way to not show the Trace Error page at all? Mike, copy your comment to an answer and I'll award it as such since it solves my immediate problem. – Deverill Feb 03 '14 at 19:12

2 Answers2

14

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.

Nick Barnes
  • 151
  • 1
  • 4
  • 1
    Perhaps for your situation, but for mine it was not necessary to do Nick Barnes' steps. MikeSmithDev answered quickly with a workable solution so his should be the answer, not the one 7 months later - although it very well may be good for others to see. I'm glad he posted his solution as well, but to say it should be the answer is unfair. – Deverill Jul 20 '15 at 17:50
2

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.

MikeSmithDev
  • 15,731
  • 4
  • 58
  • 89
  • Thank you! Sometimes I get so deep into a problem I barely understand that the obvious answer escapes me. I appreciate your help! – Deverill Feb 03 '14 at 19:46