[ OWASP - Montréal ]XSFR/CSFR testing difficulty level
philippe at gamache.com
Fri Nov 28 09:22:08 EST 2008
Sean Coates wrote:
>> One thing that is important to mention too is that XSRF flaws are
>> very difficult to mitigate. (At least, much more difficult than..
> I don't think it's more difficult to mitigate than SQL Injection. You
> just need to store a token on the server side, and provide the token
> (or a hash based on this token) in each form that can perform any sort
> of "dangerous" action. The provided token must be checked before
> performing the action, and it must be user- and session-specific.
> The difficult part is remembering to put it in each action/form, but
> that's also true of SQL Injection prevention.
> Chris Shiflett (my boss) has a good article on CSRF, here: http://shiflett.org/articles/cross-site-request-forgeries
> (it originally ran in php|architect's Security Corner sometime in
Even using secret token it's now enough anymore. You have to do more
(but still use the token), where you will do page follow-up and
Chris article is good and still very accurate.
You can look for : Cross-Site Request Forgeries: Exploitation and
Prevention by William Zeller and Edward W. Felten
It's a PDF I found, but I don't remember where!
As for testing, looking any entry (GET or POST) can be transform in a
CRSF. About 53% of DELETE fonctions in web application are at risque.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 131 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-montreal/attachments/20081128/0600f58c/attachment.vcf
More information about the Owasp-montreal