Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
CSRF prevention in an MHTML world
Posted by: rezn
Date: April 06, 2007 10:50PM

ok, how about this for everyone who thinks they can use MHTML to bypass any nonce/token based CSRF protection.

Require a keyed HMAC of the session id (from the cookie) to be contained somewhere in the URL of every authenticated request. All URLS generated by the application starting with the response that contains the initial Set-Cookie header need to contain this token. The Set-Cookie should be in response to a successful authentication, not before.

In this case MHTML doesn't help an attack, as you can't make any requests at all without the token. There are no pages to read and harvest tokens from, at least not without having the token first.

Since this only works if you do it on every request, there is a pretty big exposure via referer. If the same application has a redirection problem (where the attacker controls the target) its game over. This could be mitigated by making the tokens all be unique, one time use values (actual nonces) at a cost of more resources on the part of the server.

Ok, now its everyone's turn to explain why this won't work.

rezn

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: kogir
Date: April 07, 2007 04:18AM

I think your solution would work, but it's late and I might have missed something. However, wouldn't it be easier to add:

<!--
Content-Disposition: attachment

-->

to the top of every page as per http://sla.ckers.org/forum/read.php?4,1975,2037#msg-4296 ?

It seems to work for my site (or at least breaks *my* mhtml exploit code).

-kogir

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: christ1an
Date: April 07, 2007 04:18AM

Ah it's good seeing other people having the same thoughts.
I've had the same idea when PDP came up with his rather superficial blog post about preventing CSRF. Actually, I see no reason for why this should not work. Lets see what the others reply.

Edit:
Kogir, is that technique verified? I see Google using the same approach:
<!--
Content-type: Preventing XSRF in IE.

-->

Regards,
- http://christ1an.blogspot.com

_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0



Edited 1 time(s). Last edit at 04/07/2007 04:22AM by christ1an.

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: rsnake
Date: April 07, 2007 06:09PM

Or you can just remove all double line breaks. That effectively stops the exploit as well.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: christ1an
Date: April 08, 2007 03:38AM

Remove? I thought add a double line break :) Anyway, I've had some thoughts about CSRF prevention during the last weeks which I finally brought to paper yesterday. You may want to read it. http://christ1an.blogspot.com/2007/04/preventing-csrf-efficiently.html

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: rezn
Date: April 08, 2007 06:57AM

@christlan:
Nice writeup, seems to pretty much say exactly the same thing we are discussing here - the only way to prevent CSRF in the presence of cross-domain leaks like MHTML is to put the secret token in every single authenticated request.

The problem with using the same token for every request is that you leak it with the referer. And to fix this you end up implementing per-URL session ids, which is a lot of work.

@rsnake:
I understand that its currently possible to mitigate MHTML with the line breaks or MIME stuff (like google does), but how long before the next bug like this shows up? It's been what, close to six months that MHTML has been public and still no patch.

@everyone:
Clearly implementing this puts a large burden on the developer. Right now I don't see a better answer, however. Oh yeah I do, you could force your users to disable JavaScript and just use the token on a few security critical forms. :)

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: christ1an
Date: April 08, 2007 09:41AM

rezn: Yes, I says exactly what we discuss here. As I said earlier, I had the same idea a couple of weeks ago, otherwise I'd have credited you of course. In my opinion that approach is bulletproof if implemented correctly.

I wouldn't say it is a large burden for a versed developer. Meanwhile, a lot of people like to use frameworks, so I suggest to implement a framework where these things are considered. Shouldn't be too challenging.

Regards,
- http://christ1an.blogspot.com

_______________________
[[url=http://php-ids.org]php-ids.org[/url]] Web Application Security 2.0

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: Kanatoko
Date: April 10, 2007 06:50AM

christ1an , Is there a working demo of your idea?
I wanna test.

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: christ1an
Date: April 10, 2007 08:14AM

I haven't built a framework yet so therefore I actually have no working demo at the time. Anyway, if you want to try hacking the approach you can build a demo yourself.

Just make a page with a login form on it and for a valid authentication you set a cookie in response. Additionally at the same time you generate the mysterious token which will be added on each request url the system offers. Then try to bypass it.

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: Kanatoko
Date: April 10, 2007 08:22AM

OK, thanks!

--
Kanatoko
http://www.jumperz.net/

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: rsnake
Date: April 15, 2007 01:46AM

@christ1an - no, removing linebreaks will keep you safe. MHTML reads from the first double line break. However you can mess with the output of the MHTML hack by adding a double linebreak at the end and throwing in random crap, but I'm not sure what value that has. I can't comment on what the "next" hack will be or how it will work, I'm just telling you a way to mitigate that one particular hack since it was the topic title (silly me!). ;)

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: CSRF prevention in an MHTML world
Posted by: Kanatoko
Date: June 14, 2007 03:39AM

The MHTML patch has been released.

MS07-034
http://www.microsoft.com/technet/security/Bulletin/MS07-034.mspx

--
Kanatoko
http://www.jumperz.net/

Options: ReplyQuote


Sorry, only registered users may post in this forum.