Last post Sep 19, 2010 01:02 AM by mbanavige
Sep 18, 2010 10:24 PM|pbz|LINK
Let's say I have a login page that asks for a username and password. On the server side if these two match I mark something in the session variable (server side) to know that the session is logged in. From a different page, let's say in Page_Load, I check
if the current session is logged in and if not redirect to the first page.
Given the current exploit, how would it work to break in? Would they still be able to retrieve web.config? Actually, let's say we have a plain default web application, with nothing but the default.aspx page, can this site be broken into as well?
Sep 18, 2010 10:32 PM|mbanavige|LINK
If you have not implemented the recommendations in Scott Gu's blog article then your app will be vulnerable.
If anything in your site produces a peice of encrypted data that the client can get, then they can feed it to the padding oracle exploit tool (POET)
You are strongly encouraged to implement the current recommendations until a patch is released.
Sep 18, 2010 10:38 PM|pbz|LINK
I'm just trying to understand how it works. You said that if the site "produces a piece of encrypted data that the client can get"... by default there isn't any encrypted data that's sent back to the client (afaik), so how can they break anything? Thanks.
Sep 18, 2010 10:45 PM|mbanavige|LINK
The input needed to get POET working can come from a simple WebResource url
So add a simple validator to your page, and you're vulnerable.
The recommended temporary fix is relatively quick and painless for most apps. Keep in mind that it won't be necessary after a patch is released.
Sep 19, 2010 12:01 AM|pbz|LINK
Thanks. There isn't a way to disable sending that key or encrypting the resource, is there?
Sep 19, 2010 01:02 AM|mbanavige|LINK
It you're running .aspx pages, then there's most likely going to be some dynamic content sent. You don't generally add webresource urls to your pages explicitly, yet there they are. the framework adds them. 3rd party components add them.
I think the safest approach is to assume that some bit of useful data can/will make it to the client and you need to (at least for the moment) protect against the mis-use of that data.