good summary my man.

It all depends. We cannot say whether your application is secure or not. Rethink all technologies that you are using and make sure that they are applied appropriately.

This would only require 1 line of extra code client side and is faster than rewriting the dom. It also means that if you have different panels of the admin section open in separate tabs then they all have the most recent id whenever you eventually submit them (which a dom rewrite onload may not and even though a dom rewrite onsubmit would it’s less efficient). I regularly regenerate the session id so this is an issue for me.

If the user has javascript turned off, the js is incompatible with the browser or the js is just plain borked then the id will not be sent because there’s no fall back, but that isn’t a problem here since the admin section is private and for me only.

Does this method open any new holes that I haven’t noticed?

I think that you are missing the point.
MHTML bug can be prevented at the server side as same as XSS.

the MHTML bug is more dangerous than XSS

Interesting. Why?

I think XSS( and Session Hijack) is more dangerous than the MHTML bug because it can access to the response of POST.

There is NO need to put the session IDs within URLs when following this approach. Just include the session ID within form fields that would be transmitted as a POST request, and *not* within URLs:

<form action="http://target/profile.do" method="POST">
<input type="hidden" name="name" value="John"/>
<input type="hidden" name="lastname" value="Dawson"/>
<input type="hidden" name="JSPSESSIONID" value="7af7a55caff365ca594510586"/>
<input type="submit"/>
</form>

Giorgio Fedon,

This might help if you’re paranoid (disable autocomplete):

<input type="hidden" name="JSPSESSIONID" value="7af7a55caff365ca594510586" autocomplete="off"/>

But then again, if you can access the user’s machine, you can also access the session ID cookies! Hopefully, the session ID expires after the idle session timeout ends.

Kanatoko,
the MHTML bug is more dangerous then XSS and CSRF, so your statement does not make sense at all. :) sorry!

Andy,
where exactly you are going to leak the token? We are not talking about freaking blogs man. We are talking about stuff like admin interfaces or interfaces that allows you to configure your profile or whatever. Otherwise CSRFs are pointless. These interfaces should not hold external links on the first place. I do agree that sometimes we are required to use GET but if you application does an operation over GET, something must be wrong with it. I am not saying that it is not common, all I am saying is that the idea is wrong.

The idea of this post was to show that CSRF attacks can be prevented in a very simple way without too much trouble. Still, it is possible to screw up with this implementation. However, I do use this prevention mechanism no matter what people are saying and it works very well. I do know about the dangerous of leaking your session ID in the URLs but that is a problem unless you don’t know what you are doing. Look at all Google applications. The basic CSRF protection mechanism is in the URL. Can users leak that? Yes, it is possible. In theory, this means that if the user clicks on a link from an email and they arrive on some page, the browser may leak the token, right? This means that it could be possible for the website to perform CSRF, right? Well noooo, because Google does a good job to put all external links through their redirection script which eliminates all tokens from the URL.

To sum up:

There are cases where we might want to still use GET for certain operations, and in those cases we just have to be careful to not leak the token via referer.

I don’t worry about leaking the refer to proxy servers, because in cases where I’m really worried about preventing CSRF I’m going to be using SSL.