An alternative title for this post would be: “Why you should never deploy your ASP.Net application with debug set to true to a production server”.
An easy way to expose your ASP.Net website to hackers is to publish it to a production site with the debug attribute in the “compilation” element set to true. The reason for this is that exception messages are typically more verbose. Hackers try and make your website throw an exception, because they can then use the verbose exception messages to determine names of database tables and fields as well as property names in your application’s classes. In addition, deploying an application with debug set to true results in:
- The compilation of ASP.NET pages takes longer (as batch compilation is turned off)
- Code typically executes slower
- Memory footprint is increased
- Scripts and images downloaded from the WebResources.axd handler are not cached
- Requests do not time out (this is bad, as in a production environment we dont want requests to be stuck indefinitely)
The obvious fix is to remember to set debug=false whenever you publish your website to a production environment. But what if you forget to set debug=false? This was something that always worried me…
And today I found out about the deployment element…
What makes the deployment element special is that it is a machine level configuration element. When its retail attribute is set to true, it will disable the <compilation debug=”true”> for ALL ASP.Net applications running on that machine. In addition, it turns of detailed errors messages being sent to remote machines and disables the ability to trace output.
Here is how you set it (remember this is not an application level, web.config element, and is set only in the machine.config file, typically found in “%windir%\microsoft.net\Framework\[VersionNumber]\CONFIG”)
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>
2 comments:
When I copy your deployment line on this page to paste it in the machine.config file, Server Manager and IIS Manager can't be run anymore. I found out this is because of the double quotes you use.
This is a detail but I must admit I spent some long minutes before finding it.
A good post informing those who are not familiar with these issues.
Another fix to the problem would be to use the ASP.NET Web Deployment Project which can swap out parts of your config files for a live environment. Where I work, we have three seperate config file types (dev/test/live) and when the deployment project is compiled, we can set which configs are placed into the web.config.
Post a Comment