Twitter Hijacking

[softreset64738 at gmail.com (Soft Reset)]

Yeah, I see.  So the 'authenticity_token' they have is can still be
eavesdropped but will prevent, as you say, browser GET/POST requests.  But
to 'insert' a img tag, hidden iframe etc, doesn't the attacker have to be
"in the middle" anyway?

On Fri, Nov 20, 2009 at 7:52 PM, Knight, Brandon <kaospunk at gmail.com> wrote:

> 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.<http://en.wikipedia.org/wiki/Cross-site_request_forgery#cite_note-Shiflett-0>
> [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
>
>
>
> _______________________________________________
> 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/360e7443/attachment.htm