Continuing with my last post on vulnerabilities in web applications due improper use of crypto, lets look at what might happen if you reuse an internal method for encrypting data.
Consider a web application that needs to encrypt an application cookie. The developer uses the CookieProtectionHelper.Encode method to encrypt it. CookieProtectionHelper.Encode is an internal method, was introduced in ASP.NET 2.0 and is internally used by the framework to encrypt the RoleManager cookie.
The code simply accepts a form field from the user, encrypts it using CookieProtectionHelper.Encode (invoked using reflection), and adds the output to the response as a cookie.
Incidentally, the web application uses ASP.NET Forms authentication. What the developer has not realized is that ASP.NET Forms authentication, to encrypt the authentication cookie, uses the same logic and keys as the CookieProtectionHelper.Encode method.
As a result, an attacker can send a specially crafted input in the form field and get it encrypted. This encrypted blob can then be used as the authentication cookie to log in as another user, thereby bypassing the authentication controls!
This is a classic case of lack of key separation, where the same symmetric key has been used for two purposes. In one use case, the end user completely controls the plain text to be encrypted and then can use the cipher text obtained in the other use case to attack the application.
Recommendation:- Avoid using the same cryptographic key for multiple purposes without fully understanding the system. Also be careful when reusing crypto methods written by others or written for a different purpose, specially when the end user completely controls the text getting encrypted or signed.
HttpSecureCookie, A Way to Encrypt Cookies with ASP.NET 2.0
Understanding Role Management
Explained: Forms Authentication in ASP.NET 2.0
Key separation and constraints on key usage, Chapter 13, Handbook of Applied Cryptography by A. Menezes, P. van Oorschot and S. Vanstone.
Security Engineer, ACE Team