Considering the recent ASP.NET vulnerability, what should I look for in my httphandlers that would cause such a Padding Oracle vulnerability?
Asked in another way... what did MSFT do wrong and what did they fix in their handlers?
views:
14answers:
2
A:
I think the wronge is that they give "too much" informations about the error.
@Sri here analyze it very well
http://stackoverflow.com/questions/3720720/how-serious-is-this-new-asp-net-security-vulnerability-and-how-can-i-workaround-i/3721473#3721473
Aristos
2010-10-29 00:47:37
Which error? How would I improperly implement the same thing in my code?
MakerOfThings7
2010-10-29 00:50:46
@MakerOfThings7 The error that you get when you give a false key to decrypt.
Aristos
2010-10-29 00:52:33
A:
There were 3 problems with WebResource.axd and ScriptResource.axd:
- Working as a padding oracle. This is because these decrypted information send in the query string, and behaved differently when the decrypted string had invalid vs. valid padding - because it had been tampered with. The fix Microsoft made included using a HMAC to prevent the data from being tampered - this is checked before any padding check, so it doesn't expose padding information
- Relying on normal encryption/decryption to receive a request for a resource/file. It isn't meant for that, a tamper proof mechanism is needed.
- Allowing access of any kind of files, not only JavaScript files
Bottom line, don't allow more access than necessary and only if you really need encryption/decryption tamper proof it.
Back in the day I blogged about how it related to getting different levels of access
eglasius
2010-10-29 03:52:50