[WEB SECURITY] How are you tackling CSRF?

MustLive mustlive at websecurity.com.ua
Tue Apr 26 21:06:38 EDT 2011


Hi Jim!

"Prevention Cheat Sheet" - sounds interesting. It's good to know that OWASP
made such Prevention Cheat Sheet and particularly for CSRF (as I saw there
are other Prevention Cheat Sheets). This will be helpful for web developers
to create reliable protections against this issue. For example, sometimes
web developers ask me about methods to protect against CSRF. So instead of
long description about pro and contra of different protection methods, it'll
be simpler to give people read this document.

> Hang on a sec. W3C recommendations state that GET requests should be
> idempotenent

First, many developers use tokens for GET requests (for example I more
prefer to user referer checking for GET requests).

Second, how many developers reads W3C recommendations.

Third, I was talking about internal forms (in users account, i.e.
post-authorization form), and in such case not W3C with their
recommendations, nor Akamai will see anything in that users account of that
site, so there will be no questions and no issues which you mentioned
concerning tokens in GET request.

Fourth and the most important - if there is a functionality (accessible via
GET or POST) which can be subject to CSRF attack and so need to be secured
against them, it must be secured. If developers have choose tokens, then by
tokens - regardless GET or POST is it and any W3C can't stopped the securing
process. And generally there must be no such official standards or
recommendations that decrease security of sites and web applications ;-).

So in that case it was looking as developers laziness. Especially if they
put tokens not only to POST forms, but to some GET links, but not all
(leaving part of the holes unfixed). Also sometimes I saw selective approach
from developers - as from my clients, as in CMS (it's already not laziness,
but developers decision where to make anti-CSRF protection and where not).
For example I saw such cases in WordPress, Drupal and Joomla - and in
particular they concerned GET requests, some of which had tokens and some
not. But there are such engines where every functionality is protected 
against CSRF, so it depends on developer.

Besides, last Thursday I wrote an article "Attacks on unprotected login
forms" (soon I'll post English version of it to the list), where I also
mentioned about CSRF attacks.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: James Manico
To: MustLive
Cc: <websecurity at lists.webappsec.org>
Sent: Sunday, April 24, 2011 11:27 PM
Subject: Re: [WEB SECURITY] How are you tackling CSRF?


> Protecting only POST requests with tokens, but not GET. It looks like
some web developers are lazy (or it's hard for them) to add tokens to GET
requests.


Hang on a sec. W3C recommendations state that GET requests should be
idempotenent (non-state changing) and therefor should not require CSRF token
protection.


Admittedly, this is the ideal. Many developers use GET requests for state
changing operations.


But GET based tokens cause serious scalability problems when you are dealing
with CDN's (content delivery networks) like Akamai.


I could go on, but the key here is that this is not about "developer
laziness". CSRF defense is more complex of a design decision than appears at
first glance.


More here:


https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Jim Manico

On Apr 23, 2011, at 3:59 PM, "MustLive" <mustlive at websecurity.com.ua> wrote:



2. Protecting only POST requests with tokens, but not GET. It looks like
some web developers are lazy (or it's hard for them) to add tokens to GET
requests.






More information about the websecurity mailing list