JSF was vulnerable to this attack; Thai and Juliano, the researchers that other HN users are trashing on this thread, also found that flaw as well. I have to assume it's been fixed by now.
Section 5.1 of this whitepaper[1] by Rizzo and Duong, that lists Ruby on Rails as one of the web frameworks vulnerable to this attack.
Granted, this paper was published in May, and I'm not a Rails guy, so it's quite possible this has been patched as well.
[1]http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf
What makes you make a comment like this? What evidence are you basing it on?
I have never worked on an ASP.NET-based site that relied upon cookies, encrypted or not, for anything. Even where the built-in forms authentication was used the username always had correlating server-side state that was triumphant.
So saying that you can modify cookies == a complete and utter non-issue for any site that followed any reasonable security practices.
You have it, right? You sound like you do.
Visual Studio Magazine [1].
I've enjoyed reading all your comments on this thread. You clearly know your stuff. Based upon what you've seen so far and what you know about the ASP.NET framework, do you see any way around this short of some patch from Microsoft?
[1] - http://visualstudiomagazine.com/articles/2010/09/14/aspnet-s...
The error message provides a small tidbit of information about how ASP.NET decrypts messages. With enough of these error messages it is possible to decrypt the message in its entirety.
What message? The cookie itself?
I agree, unless this attack completely crashes the .Net stack to allow privilege escalation or similar, it's complete hyperbole.
Whether you're right or your wrong (and I would tend to agree that storing sensitive information clientside --- or doing anything else that involves encryption --- isn't worth the risk), this isn't a productive point to make. These designs exist, and can be secure, but contain flaws that must be corrected, lest many tens of applications be susceptible to devastating attacks.
There are cases where having sensitive information in a cookie makes sense. In a web farm, for example. A session store that serves a farm of web servers is harder to set up and maintain than having clients send information back in a cookie. If it's properly encrypted, then this shouldn't be a problem. (Signed cookies are also good for this scenario, if it's okay for the data to be seen by others)
Am I wrong?
EDIT: Here's a good thread on how to ensure data on client cookies hasn't been tampered with: http://news.ycombinator.com/item?id=1687826
This allows the end user to decrypt their own "encrypted" cookie, not an attacker. At best, if the web app writers were stupid and put truly exploitable data in the cookie, they'd be effected.
It is horrible that MS missed this, but calling .NET broken is probably actionable libel.
It's not about figuring out what's in the client cookies - it's about forging cookies that the server completely trusts on account of the (broken) encryption.
The most significant new discovery is an universal Padding Oracle affecting every ASP.NET web application. In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
Even in cases where app logic will trip this approach up early (making hard assumptions about session vals having been initialized post-login and consequently failing fast, etc), the secrets are still captured.
http://al3x.net/2008/12/31/why-not-infosec.html
..the core point being,about how little attention genuine, path-breaking work gets, if security researchers DO NOT make an attempt to publicise it,quite radically.
These sure are not some random guys making a bold claim.. that work has been published in Usenix!
