4 ms·
Two possible failures: 1. Attacker makes one request. I read EvilPacket to suggest the time-limited challenge is a token stuffed into the cookie. Attacker then
by sunir 17y ago
Two possible failures:
1. Attacker makes one request. I read EvilPacket to suggest the time-limited challenge is a token stuffed into the cookie. Attacker then waits a few seconds before making the change request with the token safely in the cookie.
You should rather load a challenge in the submit form. I do recommend that for user-generated content.
http://usemod.com/cgi-bin/mb.pl?EditHash
2. However, if this page is vulnerable to HTML injection, you can get the hash back by embedding Javascript that creates another iframe or img back to yourself on the attacked page.
http://www.codecouch.com/2008/10/cross-site-scripting-xss-using-iframes/
So, I just find it safer to ask for the user's password.
- adam_baldwin 17y agoYou are absolutely right here. I guess I want to point out that I was not wrong but simply vague (I guess I need to have a bit more peer review on these things). I never said to put it in the cookie, I did say session (I meant server side).
- sunir 17y agoJust to be clear to the readers, putting the token in the session has the same vulnerability. If you're going to use a token, put it in the form.
- tptacek 17y agoSunir, CSRF challenges are embedded in forms. They're not just part of the cookie. The whole idea of a CSRF attack is that your browser can be coerced into laundering cookies for attackers. At this point, we're "discussing" something on Hacker News that even Wikipedia has right (search for "XSRF"). But if you have to think about how to handle this problem, you're doing it wrong. Use your framework's builtin XSRF protection. If your page is vulnerable to DOM injection, you have much bigger problems than XSRF.
- sunir 17y agoAs I wrote, "I read EvilPacket to suggest the time-limited challenge is a token stuffed into the cookie." I wouldn't recommend putting a challenge token in the cookie, but developers make mistakes. Also, you know DOM injection is a very common problem. It's better if you don't have to assume the website has no DOM injection problems to do the right thing. Therefore, I think it is reasonable to recommend asking password confirmation as a general best practice, since it's a straightforward way to be the safest. I'm not sure why you are arguing with that point.