Are there any security issues leaving the PDB debu

问题:

Are there any security issues keeping the .NET PDB files on the real server?

I know that throwing exceptions might take a bit longer , but who throws exceptions during normal execution anyway? :-)

But from a security perspective? any issues?

回答1:

Hmm - I'd lean on the side of security caution on this. I think you should have PDBs, but not on production servers. Besides, you should have Debug turned off on any live system. Debug is nasty, and you just don't want it when you don't need it.

From Scott Guthrie:

1. The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
2. Code can execute slower (since some additional debug paths are enabled)
3. Much more memory is used within the application at runtime
4. Scripts and images downloaded from the WebResources.axd handler are not cached

Set deployment retail=true in your machine.config:

<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>

This overrides debug, error and trace settings, which will prevent any error disclosure outside of the computer itself.

So now that you have debug turned off, no error or trace on, why would you deploy PDB's to the production server? Store them somewhere else, perhaps even your development server. Your code promotion script from Dev to Production can specifically exclude the PDBs, but archive them so that they're available if you ever need to do debugging of production.

回答2:

If your system isn't secure with the PDBs, it's probably not secure without them. Obviously, it depends how valuable the better error reports are to you. Personally, I value that a lot, so tend to deploy the PDBs.

回答3:

The only problem you may encounter when publishing .PDB files to your website is when an exception occurs, and you forgot to set the CustomErrors property in web.config. The stack trace will be displayed with file names and line numbers, which may be a security problem.

I don't think there are any other risks.

回答4:

I think a fair argument is also that not leaving the PDBs on the live servers is a risk. In the case where production is crashing and the problems can't be reproduced on dev or UAT, it's much more time consuming (and perhaps impossible) to diagnose where the error is occurring.

At the very least, the PDBs that match the deployed DLLs should be in a ZIP file on the production server somewhere. They should be easily located by people other than yourself in case you aren't around to assist.

Also see PDB Files: What Every Developer Must Know by John Robbins.

回答5:

If server is IIS, no. These files will not be exposed to the public if kept in the right places (website\bin). Occasionally I've found intermediate (obj directory) files on web servers - this appears to be a favorite way to accidentally publicize binaries. Any cases where your pdbs are visible, you dlls are also visible, which is worse.

As noted by activa, the stack trace is plenty useful to a hacker with or without line numbers. Keep it private.

I assume any other program you might be running on a real server - services, and so forth - isn't publicly accessible at all.

回答6:

If you present failing exceptions to the end-user (aka in Yellow Screen of Death), then it might pose a risk of attacker a getting better insight into your system.

One of the possible solutions - to have an exception handling policy that:

1. Logs all exceptions with the original stack trace, additional information and a unique exception ID (Guid).
2. Replaces fired exception with a wrapper that contains only exception ID (for reference and feedback) and sanitized message (i.e.: no connection strings) with discarded stack trace info.

Examples of Open Source Exception handling blocks in .NET:

• From Lokad

• From Microsoft

• Theory

回答7:

Basically PDBs are just below source code when it comes to poking about, and ASP.NET/IIS doesn't stop them from being downloaded either.

Now sure people would have to guess the assembly name, and that may be unlikely, but why take the risk?