

Hacking CSRF Tokens using CSS History Hack - profquail
http://securethoughts.com/2009/07/hacking-csrf-tokens-using-css-history-hack/

======
timf
Damn, seems so obvious in hindsight. When I learned about the CSS history
information leakage in the first place I was alarmed enough. I clear history
several times a day because of this leakage problem (and other reasons anyhow)
but that's really not often enough.

I personally don't like whitelists to solve general browsing problems but
noscript does allow you to only trust certain sites with possibly attaining
your history information by limiting their ability to run JS. I _like_ seeing
new sites with JS magic though. In general, I am leaning towards using a
separate browser entirely just for things I log in to and fully trust -- this
is just another log on that fire.

------
simonw
Interesting attack, but it only works for CSRF tokens included in a URL. If
you instead place your tokens in hidden form fields (which I recommend, since
you should only need to protect POST requests) this attack won't affect you.

~~~
timf
The problem is not applications you code, it's ones that you use. Do you stop
using a webapp once you see a session token in the URL?

~~~
tptacek
Do you notice all the other crazy bad things that the applications you use do?
This is not a particularly virulent attack.

~~~
timf
Sure. And I noticed the tokens in URLs but did not usually care that much
since they are over https which doesn't reveal the parameters. Now I do care.

------
bct
Why would you attach a CSRF token to a GET request? GET requests shouldn't do
things, so they shouldn't need to be protected against CSRF.

(I see this is mentioned in the comments there.)

~~~
timf
Putting session keys in a GET URL happens a lot (whether it "should" or not
:-)). It's an authentication scheme for access to the URL: your GET may or may
not actually have "side effects" regardless, that's orthogonal.

------
Jem
Read the comments on this one - there's some good feedback and interesting
links.

