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

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

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.

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

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

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

@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. :)

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

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

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.

OK, thanks!

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

@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

The MHTML patch has been released.

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

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