> > I agree. It seems anti-csrf (as currently defined) would be most beneficial > for defending against CSRF attacks that don't require any user action beyond > simply viewing the page (e.g., <img src="attack">). > > Form actions would perhaps require some additional constraints, such as only > allowing submission to |self| or other whitelisted URIs. >
I don't understand. In each of the cases above, the attacker site will not enable the directives and img requests or form requests from his page will cause a CSRF to occur. -devdatta 2009/10/22 Mike Ter Louw <[email protected]>: > Adam Barth wrote: >> >> 2) It seems like an attacker can easily circumvent this module by >> submitting a form to attacker.com and then generating the forged >> request (which will be sent with cookies because attacker.com doesn't >> enables the anti-csrf directive). > > I agree. It seems anti-csrf (as currently defined) would be most beneficial > for defending against CSRF attacks that don't require any user action beyond > simply viewing the page (e.g., <img src="attack">). > > Form actions would perhaps require some additional constraints, such as only > allowing submission to |self| or other whitelisted URIs. > > Link activation is harder, because (I would assume) most websites want to > allow links to different-origin URIs. And as you stated, not sending > cookies here doesn't help because the link could go to attacker.com, and the > page can contain an image based CSRF (thus the threshold for successful > attack is still 1 click). > > Thanks for the feedback, > > Mike > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
