No, if there are no CSRF/XSRF protections in place, all that is needed is for the victim to be logged into the target website and visit the attackers website or a website they control. The 'evil' website can have javascript/img tags/etc that will cause the victim browser to perform the needed GET/POST requests to perform the action that the attacker wishes to have performed.
On Fri, Nov 20, 2009 at 11:31 PM, Soft Reset <[email protected]>wrote: > 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 <[email protected]>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 < >> [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 >> >> >> >> _______________________________________________ >> 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
