Twitter Hijacking

[softreset64738 at gmail.com (Soft Reset)]

Interesting.  Wikipedia seemed to consider CSRF and XSRFs the same.  Either
way, I did wonder if this token changed so I took a look at different
Twitter forms to see and whether I submitted information or just went to
view other forms, the token remained the same.

On Fri, Nov 20, 2009 at 6:03 PM, John Miller <johnemiller at gmail.com> wrote:

> For CSRF, the token just needs to change for each submission. It can only
> be used once, so sniffing it is pointless. I didn't take a closer look at
> exactly how Twitter handles this, but generally, a cookie will store the
> Authentication data while a hidden field stores a per-request token to
> prevent CSRF.
>
> What this is protecting against is a 3rd party site including something
> like <img src="http://twitter/doSomthingBad";>. Since they won't have the
> single use token, that request can't do anything.
>
> On Fri, Nov 20, 2009 at 6:38 PM, Soft Reset <softreset64738 at gmail.com>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/9cd50ca5/attachment.htm