[WEB SECURITY] How are you tackling CSRF?

Rohit Pitke rohirp92 at yahoo.com
Sat Apr 23 00:54:01 EDT 2011


As far as our experience goes, if post-login, some forms do not contain 
anti-CSRF tokens, it is fair chance that rest of forms will also be the same. I 
have seen a notion among developers that we are using POST request and hence we 
are safe. So we have recently formulated following strategy


	1. Check out important enough pages post-login and check their session state.
	2. If session is found to be maintained only in cookies, assume that whole 
application is CSRF prone.
	3. Take a help of automated scanners, train them a little bit and generate 
report.
	4. Get it fixed from our developers. 
For point(2), questions comes how to check if session is maintained only in 
cookies. We can validate this by carefully observing requests through proxy. 
Now, lately I have seen some cases where there is anti-CSRF tokens but there is 
no validation of them   :)  . So we generally implement it like


	1. All sensitive requests SHOULD be POST with https (in most of the cases).
	2. Generate hidden parameter and attach it to the form. This is anti-CSRF 
token. We normally take set their value same as session cookies.
	3. Once this form is submitted, we check if cookie-value = value of 'that' 
hidden parameter.
	4. For GET requests, we normally attack anti-CSRF token in query string or we 
make sure that they are not prone to XSS at all.Regards,
Rohit






________________________________
From: Jeremiah Grossman <jeremiah at whitehatsec.com>
To: web security <websecurity at webappsec.org>
Sent: Sat, April 23, 2011 12:00:54 AM
Subject: [WEB SECURITY] How are you tackling CSRF?

Hi All,

    Over the last year I've been noticing increased interest and awareness of 
Cross-Site Request Forgery (CSRF). A welcome change as for most of the last 
decade few considered CSRF a vulnerability at all, but an artifact of the way 
the web was designed. But, the as it normally happens, the bad guys have been 
showing us how damaging CSRF can really be. 


To help bring more clarity we've recently published a detailed blog post 
describing how our testing methodology approaches CSRF. What we're interested is 
how other pen-testers and developers are tackling the issue because automated 
detection is currently of limited help.

WhiteHat Security’s Approach to Detecting Cross-Site Request Forgery (CSRF)
https://blog.whitehatsec.com/whitehat-security%E2%80%99s-approach-to-detecting-cross-site-request-forgery-csrf/


FYI: Several weeks ago we launched our new blog, where I'll be diverting all my 
web security material. We've been piling up new content: 
https://blog.whitehatsec.com/


Regards,

Jeremiah Grossman
Chief Technology Officer
WhiteHat Security, Inc.
http://www.whitehatsec.com/


_______________________________________________
The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity at lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110422/ccfd7f33/attachment-0003.html>


More information about the websecurity mailing list