By now many of you have heard of the ASP.NET Oracle Padding Flaw. There’s a number of posted workarounds, and MS will be issuing a patch soon to fix things.
The problem lies in the way that ASP.NET, Microsoft’s popular Web framework, implements the AES encryption algorithm to protect the integrity of the cookies these applications generate to store information during user sessions. A common mistake is to assume that encryption protects the cookies from tampering so that if any data in the cookie is modified, the cookie will not decrypt correctly. However, there are a lot of ways to make mistakes in crypto implementations, and when crypto breaks, it usually breaks badly.
The issue here seems to be that there’s *anything* of value stored in the cookie beyond a generic token. This really does seem to be the case though. Watching the DNN exploit, it looks like the fact that someone is a superuser is encoded in the cookie value itself. This would seem to be an architectural flaw in DNN, but I get the feeling that most ASP.NET apps were/are trusting of the encyrption mechanism to hide whatever data they’re sending down in cookies. This seems to be a more fundamental flaw in design than any AES algorithm MS may have had an issue with.
I’m reminded of a company I worked for years ago which kept track of sessions by incrementing a counter in a DB, grabbing that counter, encrypting it, then using that value as the value in the cookie. This was thought of as ‘secure’ because encryption was being used. I tried to argue for random values as the cookie token, but was told that ‘random isn’t really random’. I pointed out that dozens of people (who no longer worked there) had access to the encryption key, and once I knew how to decrypt one token – which would give me a value, of, say 4554678, changing the value to 4554672 then reencrypting would be trivial and allow me to impersonate other users on the system. My concerns were dismissed because I wasn’t a ‘senior’ engineer, apparently I didn’t understand Java or cryptography enough to understand their level of sophistication. After all, ‘random isn’t really random’.
This approach of putting sensitive data in a cookie, then encrypting it, seems to be alive and well, and that scares me. But I have no real good way of opting out of such sites.
So my question (yes I had one) is… is my understanding of what ASP.NET apps are doing that make this flaw so dangerous an accurate understanding? Or have I missed something?
I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!