Twitter Hijacking

[kaospunk at gmail.com (Knight, Brandon)]

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.com 
> > wrote:
> 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