3 ms·
I just want to highlight that Cloudkick did the right thing and required password confirmation to change the email address. The attacker, EvilPacket, recommend
by sunir 17y ago
I just want to highlight that Cloudkick did the right thing and required password confirmation to change the email address.
The attacker, EvilPacket, recommended the wrong thing. They wrote, "The best protection I have seen so far is to use tokens that are time sensitive, tied to the user session and verified when the request is submitted back to the server."
The reason that is wrong is because the attacker can request a new token using the same method it submits a change.
Email and passwords work as challenges as they both cycle through the human being that owns the account, rather than just the browser. it's important to have more than one method that is tied to the account owner because if you want to change one, you need to use the other to confirm.
- tptacek 17y agoThe attacker cannot get a new challenge, because in a CSRF attack the attacker never got to see the challenge to begin with. CSRFs are blind drive-by attacks.
- sunir 17y agoTwo 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.
- adam_baldwin 17y agoDefense in depth. Nothing wrong with multiple solutions. You are absolutely correct that what they implemented as a great defense tactic. However, sometimes asking for credentials again to perform a privileged action is not acceptable for an application. I will admit that tokens are bad if XSS is possible as tokens can possibly be obtained by the attacker.