After reading this post, .Net and Business Intelligence: Application Security Vulnerabilities in Web.config File, what occurred to me was all this could be mitigated by employing a strategy I refer to as composition scripting.
While I've done a bit with build automation I've also created NAnt scripts that I refer to as composition scripts. The purpose of a composition script is to automate all the tasks required to prepare an application for deployment. I've used them to create ClickOnce deployments, but for web applications a composition script generally grabs all the pages and binaries needed. But in addition to that, and this is the relevant bit, I make use of the XmlPeek and XmlPoke tasks to swap out web.config tags to use configuration values appropriate for the environment being composed.
You see, my script accepts a parameter called Target.Environment. The acceptable values for that parameter are QA, UAT, PROD - quality assurance, user acceptance testing and production, respectively. (Where's development, you may ask? Well, that's the default state of the web.config in the source code repository). Along side the web.config I have a few files named web.config.qa, web.config.uat and web.config.prod. These are not repeats of the entire web.config file, though, but rather are the configuration values that need to change from environment to environment. These are the values swapped into the config using XmlPeek and XmlPoke.
Note: I believe a composition script should not recompile the application. It should compose the application deployment using the same pages and binaries as the application progresses from QA testing to UA testing and into production. This ensures the application being deployed is the same application which underwent testing.
So using composition scripts it's easy to mitigate the 10 security risks identified in the article.
