A lot of people have spoken about the Microsoft vulnerability, but I´ve missed one thing in all of this...
First, I have to recognize that Microsoft designed very well this technology, and the proof is that, on my experience, a server developed on .NET is harder to exploit that Java/PHP. A default component (think on an ASP.NET ComboBox or DropDownList) includes enough validations against modifications that push us to try harder, focusing on the design errors or in the components that were developed from scratch (think about that beautiful upload feature ;p).
So, we have a cool technology (.NET) with a lovely design that is protected with sound cryptography. However, as the crypto seems to be "unbreakable", we feel brave enough to:
- Put the configuration file (Web.config) on the root of the published web folder.
- Have a nice script (WebResource.axd / ScriptResource.axd) able to deliver any (afaik) file on the web root.
The problem is that, eventually, the enemies will find a weakness on the only defense of our castle (cryptography), and all we know how the story ends... another good tale for Defense In Depth.
Finally a patch was released, but previously to these days, I read all the mitigations that were published by Microsoft and I missed one...
Ok, on the Web.config we have plenty of critical information (database credentials, encryption keys,...). So, why we don´t recommend to encrypt this information? Maybe I'm missing something, but with this remediation, the client will be able to sleep better using Defense In Depth (Protected Storage).
