PaulDotCom mailing list archives
Twitter Hijacking
From: kaospunk at gmail.com (Knight, Brandon)
Date: Fri, 20 Nov 2009 19:52:54 -0800
CSRF tokens are not used to protect against man-in-the-middle attacks. If somebody can MITM they can see and do whatever they want to your HTTP requests and/or responses. A CSRF token is designed to protect against a remote attack where somebody forces a victim's browser to GET/POST a request to the site they are targeting. This can be done by using img tags, hidden iframes, etc to obscure this secondary request form being noticed by the victim. The CSRF token is available only within the DOM(or in cookies) of the site it is placed on and, given good design and enforcement of the same origin policy, should only be known to the user of the site and the site itself. The only way, as an attacker, to obtain it would be either through brute force, exploiting poor design such as weakly selected tokens, or potentially through poor trust relationships such as exploiting third party javascript running on the site. Make sense? -Brandon On Nov 20, 2009, at 4:38 PM, Soft Reset wrote:
Makes sense if the connection protected the token. According to Wikipedia, "Requiring a secret, user-specific token in all form submissions prevents CSRF; the attacker's site can't put the right token in its submissions.[1]" But if the form Twitter returns (containing the token) is returned over HTTP (which it is), the token is not secret and does not need to be predicted...just eavesdropped. Does this sound right or am I way off and misunderstanding the whole concept of XSRFs? --sr6 On Fri, Nov 20, 2009 at 3:23 PM, Chris Biettchert <chris.biettchert at gmail.comwrote:The authenticity_token is used for for xsrf protection. It works as intended as long as it can not be predicted for another user. On Fri, Nov 20, 2009 at 10:36 AM, Soft Reset <softreset64738 at gmail.com> wrote: I just noticed it and was wondering if anyone else had. Twitter has their "authenticity_token" as a 'hidden' input on forms...including password changes, resets, etc. Anyone tried hijacking a twitter login to verify this is bad form (no pun intended)? Don't want to re-invent the wheel if someone already did it. If someone has tried it successfully, has it been brought up to the twitter folks as a push for full SSL sessions? (yeah, I know SSL is also having issues at the moment, but still...) --sr6 _______________________________________________ Pauldotcom mailing list Pauldotcom at mail.pauldotcom.com http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com _______________________________________________ Pauldotcom mailing list Pauldotcom at mail.pauldotcom.com http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com _______________________________________________ Pauldotcom mailing list Pauldotcom at mail.pauldotcom.com http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pauldotcom.com/pipermail/pauldotcom/attachments/20091120/2a5b665c/attachment.htm
Current thread:
- Twitter Hijacking Soft Reset (Nov 20)
- Twitter Hijacking Chris Biettchert (Nov 20)
- Twitter Hijacking Soft Reset (Nov 20)
- Twitter Hijacking John Miller (Nov 20)
- Twitter Hijacking Soft Reset (Nov 20)
- Twitter Hijacking Knight, Brandon (Nov 20)
- Twitter Hijacking Soft Reset (Nov 20)
- Twitter Hijacking Chris Biettchert (Nov 22)
- Twitter Hijacking Soft Reset (Nov 20)
- Twitter Hijacking Chris Biettchert (Nov 20)