[ OWASP - Montréal ]XSFR/CSFR testing difficulty level

Philippe Gamache 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..  
>> SQLi)
> 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  
> 2004).

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
confirmations pages.

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...
Name: philippe.vcf
Type: text/x-vcard
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 mailing list