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 < [email protected]> 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 <[email protected]>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 >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com >> > > > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com >
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
