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....

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.

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.

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.

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.

@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!). ;)