[CKAN-Security] Fwd: /util/redirect and referrer-based CSRF mitigation

[David Read]

Thrawn,

According to this, when a browser is redirected it will always use a
GET on the new location:

http://programmers.stackexchange.com/questions/99894/why-doesnt-http-have-post-redirect

Indeed when a user selects say German language in the CKAN drop-down,
the browser POSTs the url "/de/" to /util/redirect, which returns a
302 redirect and then the browser GETs the new url "/de/". i.e. the
last request is not a POST.

So do you agree that the redirect wouldn't help a CSRF attack?

David

On 17 November 2014 23:36, Thrawn <shell_layer-github at yahoo.com.au> wrote:
>
> Thanks, David. No, I'm not on the list. I guess that would be a good idea...
>
> We're setting up referrer-based defences on our CKAN instances using the following Apache config:
>
>     RewriteEngine On
>
>     # block cross-domain posts except API
>     RewriteCond %{REQUEST_METHOD} !(GET|HEAD|OPTIONS)
>     RewriteCond %{REQUEST_URI} !/api\b [NC]
>     RewriteCond %{HTTP_REFERER} !https://<server name>/ [NC]
>     RewriteCond %{HTTP:Origin} !https://<server name>$ [NC]
>     RewriteRule / - [F]
>
>     # block cross-domain access to user pages except login page
>     RewriteCond %{HTTP_REFERER} !https://<server name>/ [NC]
>     RewriteCond %{HTTP:Origin} !https://<server name>$ [NC]
>     RewriteCond %{REQUEST_URI} !/user/login$ [NC]
>     RewriteRule user - [F]
>
> The first block is a general CSRF protection; the second is meant to stop exfiltration of user details (like password reset keys) using JSONP. Which is a whole separate vulnerability...
>
> My concern here is whether /util/redirect allows attackers to bypass the check for POST requests (which is what we're blocking), or whether the redirection only helps GET requests.
>
> Checking for the specific page would work for Referrer, but we want to support Origin too, for those browsers that might send it.
>
> Thrawn
>
> ------------------------------
> On Mon, Nov 17, 2014 9:16 PM AEDT David Read wrote:
>
>>Sorry, I didn't know if you are on the list and would get that email,
>>so forwarded below.
>>
>>D
>>
>>---------- Forwarded message ----------
>>From: David Read <david.read at hackneyworkshop.com>
>>Date: 17 November 2014 10:15
>>Subject: Re: [CKAN-Security] /util/redirect and referrer-based CSRF mitigation
>>To: CKAN Security Alerts/Discussions <security at lists.okfn.org>
>>
>>
>>Thrawn,
>>
>>Great that you're talking about adding in basic CSRF protection by
>>checking the referrer. Can you simply disallow requests that are
>>referred by the redirect page?
>>
>>David
>>
>>On 16 November 2014 23:56, Thrawn <shell_layer-github at yahoo.com.au> wrote:
>>>
>>> Hi, folks.
>>>
>>> As mentioned at https://github.com/ckan/ckan/issues/1419, the open redirect on /util/redirect is a concern because it allows attackers to bypass referrer checks. Which aren't a great defence against CSRF in the first place, of course, but they're the simplest to implement without touching the codebase.
>>>
>>> Can anyone clarify whether this would restrict attackers to GET requests, or whether it would also allow forgery of referrer on cross-site POSTs?
>>>
>>> Thrawn
>>> _______________________________________________
>>> CKAN security
>>> https://lists.okfn.org/mailman/listinfo/security
>>> https://lists.okfn.org/mailman/options/security/david.read%40hackneyworkshop.com
>>>
>>> Repo: https://github.com/ckan/ckan-security
>