Issue with CsrfViewMiddleware and "referer" checking for trusted and secure subdomains

[Troy Grosfield]

I have the following domain and subdomains both are trusted and both are 
secure (https):

   - https://example.com
   - https://api.example.com

When making POST ajax request from *https://example.com* to 
*https://api.example.com* I see the following error message:


   1. detail: "CSRF Failed: Referer checking failed - 
   https://example.com/path/to/some/url does not match 
   https://api.example.com/.";


Which takes me to the *CsrfViewMiddleware* where I see *same_origin* 
checking:

# Note that request.get_host() includes the port.
good_referer = 'https://%s/' % request.get_host()
if not same_origin(referer, good_referer):
reason = REASON_BAD_REFERER % (referer, good_referer)
return self._reject(request, reason)

I trust my subdomain, but there's no way for this code to actually pass 
this validation.  Am I just missing something?  Why would trusted 
subdomains fail validation here?  Can't this at least be a setting 
something like *TRUSTED_SUBDOMAINS* that's also checked?

The other option I see here it to override the *CsrfViewMiddleware's* 
*process_view* method as others have done 
. 
  However, it ends up being a rather extensive rewrite for only the few 
lines, that are mentioned above, that need to change.  Can we rewrite the 
*CsrfViewMiddleware 
*to be more modular so it's easy to subclass and overwrite pieces of the 
csrf vallidation?  Something along the lines of:

class CsrfViewMiddleware(object):

def process_view(self, request, callback, callback_args, 
callback_kwargs):

[...]

# Assume that anything not defined as 'safe' by RFC2616 needs 
protection
if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
[...]
if request.is_secure():
[...]

# Note that request.get_host() includes the port.
good_referer = 'https://%s/' % request.get_host()
if not self.is_same_origin(referer, good_referer):
reason = REASON_BAD_REFERER % (referer, good_referer)
return self._reject(request, reason)

[...]
return self._accept(request)

def is_same_origin(self, referer, good_referer):
return same_origin(referer, good_referer):


 This at least gives the ability to override the *is_same_origin* method 
which would allow us to also check for legit subdomains (in this case 
https://api.example.com).

Thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/de9c2aca-c307-4715-b5e0-334a42bd6c2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with CsrfViewMiddleware and "referer" checking for trusted and secure subdomains

[Troy Grosfield]

Don't want to do csrf_exempt because I need csrf protection since I'm 
posting data to the api. This works in cases where the site isn't secure 
(https), but once the code is moved to prod (secure site) it fails.


On Thursday, May 28, 2015 at 11:09:04 PM UTC-6, Josh Smeaton wrote:
>
> Forgive me, but wouldn't you just declare those views as csrf_exempt? A 
> csrf token at one site isn't going to be valid at another, right?
>
> On Friday, 29 May 2015 13:44:42 UTC+10, Troy Grosfield wrote:
>>
>> I have the following domain and subdomains both are trusted and both are 
>> secure (https):
>>
>>- https://example.com
>>- https://api.example.com
>>
>> When making POST ajax request from *https://example.com 
>> <https://example.com>* to *https://api.example.com 
>> <https://api.example.com>* I see the following error message:
>>
>>
>>1. detail: "CSRF Failed: Referer checking failed - 
>>https://example.com/path/to/some/url does not match 
>>https://api.example.com/.";
>>
>>
>> Which takes me to the *CsrfViewMiddleware* where I see *same_origin* 
>> checking:
>>
>> # Note that request.get_host() includes the port.
>> good_referer = 'https://%s/' % request.get_host()
>> if not same_origin(referer, good_referer):
>> reason = REASON_BAD_REFERER % (referer, good_referer)
>> return self._reject(request, reason)
>>
>> I trust my subdomain, but there's no way for this code to actually pass 
>> this validation.  Am I just missing something?  Why would trusted 
>> subdomains fail validation here?  Can't this at least be a setting 
>> something like *TRUSTED_SUBDOMAINS* that's also checked?
>>
>> The other option I see here it to override the *CsrfViewMiddleware's* 
>> *process_view* method as others have done 
>> <http://bash-shell.net/blog/2014/aug/16/django-cors-and-csrf-validation/>. 
>>   However, it ends up being a rather extensive rewrite for only the few 
>> lines, that are mentioned above, that need to change.  Can we rewrite the 
>> *CsrfViewMiddleware 
>> *to be more modular so it's easy to subclass and overwrite pieces of the 
>> csrf vallidation?  Something along the lines of:
>>
>> class CsrfViewMiddleware(object):
>>
>> def process_view(self, request, callback, callback_args, 
>> callback_kwargs):
>>
>> [...]
>> 
>> # Assume that anything not defined as 'safe' by RFC2616 needs 
>> protection
>> if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
>> [...]
>> if request.is_secure():
>> [...]
>> 
>> # Note that request.get_host() includes the port.
>> good_referer = 'https://%s/' % request.get_host()
>> if not self.is_same_origin(referer, good_referer):
>> reason = REASON_BAD_REFERER % (referer, good_referer)
>> return self._reject(request, reason)
>>
>> [...]
>> return self._accept(request)
>>
>> def is_same_origin(self, referer, good_referer):
>> return same_origin(referer, good_referer):
>>
>>
>>  This at least gives the ability to override the *is_same_origin* method 
>> which would allow us to also check for legit subdomains (in this case 
>> https://api.example.com).
>>
>> Thoughts?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8ca9b82f-80d5-405d-862f-d8a87de118da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with CsrfViewMiddleware and "referer" checking for trusted and secure subdomains

[Troy Grosfield]

Thanks @andre for the idea.  I have seen the stuff from django-cors-headers 
and use that app in my app.  However, I can't help, but feel like changing 
the *request.MEA['HTTP_REFERER']* feels way to hacky for my liking. I know 
this would work as a workaround until the ticket that @ramiromorales 
pointed it is completed (thanks @ramiromorales for pointing that out):

   - https://github.com/django/django/pull/4337
   
Would be happy to help with that ticket where possible!  Good to see it's 
getting resolved!

Troy

On Friday, May 29, 2015 at 4:11:24 AM UTC-6, Ramiro Morales wrote:
>
> On Fri, May 29, 2015 at 12:41 AM, Troy Grosfield 
> > wrote: 
> > 
> > I have the following domain and subdomains both are trusted and both are 
> secure (https): 
> > 
> > https://example.com 
> > https://api.example.com 
> > 
> > When making POST ajax request from https://example.com to 
> https://api.example.com I see the following error message: 
> > 
> > detail: "CSRF Failed: Referer checking failed - 
> https://example.com/path/to/some/url does not match 
> https://api.example.com/."; 
> > 
> > 
> > Which takes me to the CsrfViewMiddleware where I see same_origin 
> checking: 
> > 
> > # Note that request.get_host() includes the port. 
> > good_referer = 'https://%s/' % request.get_host() 
> > if not same_origin(referer, good_referer): 
> > reason = REASON_BAD_REFERER % (referer, good_referer) 
> > return self._reject(request, reason) 
> > 
> > I trust my subdomain, but there's no way for this code to actually pass 
> this validation.  Am I just missing something?  Why would trusted 
> subdomains fail validation here?  Can't this at least be a setting 
> something like TRUSTED_SUBDOMAINS that's also checked? 
>
> See ticket [1]24496, it's associated [2]PR and e.g. thios [3]comment. 
>
> Any help in advancing the issue (e.g. reviewing the patch and adding 
> the missing documentation changes) is welcome. 
>
>
> 1. https://code.djangoproject.com/ticket/24496 
> 2. https://github.com/django/django/pull/4337/files 
> 3. https://code.djangoproject.com/ticket/16010#comment:3 
>
> -- 
> Ramiro Morales 
> @ramiromorales 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/739a0c21-5ce7-452b-9a89-8b1c5cd35e34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue with CsrfViewMiddleware and "referer" checking for trusted and secure subdomains

[Troy Grosfield]

This same issue is being discussed here as well:

   - https://groups.google.com/forum/#!topic/django-developers/tEEw02RhV0M
   


On Friday, May 29, 2015 at 8:23:43 AM UTC-6, Troy Grosfield wrote:
>
> Thanks @andre for the idea.  I have seen the stuff from 
> django-cors-headers and use that app in my app.  However, I can't help, but 
> feel like changing the *request.MEA['HTTP_REFERER']* feels way to hacky 
> for my liking. I know this would work as a workaround until the ticket that 
> @ramiromorales pointed it is completed (thanks @ramiromorales for pointing 
> that out):
>
>- https://github.com/django/django/pull/4337
>
> Would be happy to help with that ticket where possible!  Good to see it's 
> getting resolved!
>
> Troy
>
> On Friday, May 29, 2015 at 4:11:24 AM UTC-6, Ramiro Morales wrote:
>>
>> On Fri, May 29, 2015 at 12:41 AM, Troy Grosfield 
>>  wrote: 
>> > 
>> > I have the following domain and subdomains both are trusted and both 
>> are secure (https): 
>> > 
>> > https://example.com 
>> > https://api.example.com 
>> > 
>> > When making POST ajax request from https://example.com to 
>> https://api.example.com I see the following error message: 
>> > 
>> > detail: "CSRF Failed: Referer checking failed - 
>> https://example.com/path/to/some/url does not match 
>> https://api.example.com/."; 
>> > 
>> > 
>> > Which takes me to the CsrfViewMiddleware where I see same_origin 
>> checking: 
>> > 
>> > # Note that request.get_host() includes the port. 
>> > good_referer = 'https://%s/' % request.get_host() 
>> > if not same_origin(referer, good_referer): 
>> > reason = REASON_BAD_REFERER % (referer, good_referer) 
>> > return self._reject(request, reason) 
>> > 
>> > I trust my subdomain, but there's no way for this code to actually pass 
>> this validation.  Am I just missing something?  Why would trusted 
>> subdomains fail validation here?  Can't this at least be a setting 
>> something like TRUSTED_SUBDOMAINS that's also checked? 
>>
>> See ticket [1]24496, it's associated [2]PR and e.g. thios [3]comment. 
>>
>> Any help in advancing the issue (e.g. reviewing the patch and adding 
>> the missing documentation changes) is welcome. 
>>
>>
>> 1. https://code.djangoproject.com/ticket/24496 
>> 2. https://github.com/django/django/pull/4337/files 
>> 3. https://code.djangoproject.com/ticket/16010#comment:3 
>>
>> -- 
>> Ramiro Morales 
>> @ramiromorales 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1738c002-5902-4513-a740-172efddfdf45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback #24496 - Check CSRF Referer against CSRF_COOKIE_DOMAIN

[Troy Grosfield]

I just recently posted on the same issue:

   -  https://groups.google.com/forum/#!topic/django-developers/6kUiODYObnU
   
I definitely would like to see some change to make communicating between 
trusted subdomains easier.  In my case it's *https://example.com* posting 
data to *https://api.example.com* which currently fails csrf referer 
validation when using a secure (https) site.

*My thoughts on the proposed fix:*

I don't have any issues with validating against the CSRF_COOKIE_DOMAIN.  I 
would like to say I'll always own my subdomains, but who knows, that could 
change in the future and that may not be everyone else's same opinion.  I 
have worked with other companies that subdomains were passed off to 
different organizations within the company so all sites technically didn't 
have the same owner.  Yes, we should trust other orgs in our same company, 
but the point is, the root owner of *https://example.com* was not in fact 
the owner of all subdomains.  In this case, I wouldn't want 
CSRF_COOKIE_DOMAIN checking, but instead a more explicit approach (see 
below).

The other thought here would be to add an additional setting that more be 
explicit than *CSRF_COOKIE_DOMAIN*.  Instead, add a new setting, something 
like *CSRF_WHITELIST_ORIGINS,*  that explicitly calls out which origins are 
legit.  This would handle the case better than the "one-size-fits-all" 
CSRF_COOKIE_DOMAIN matching.  Inside CSRF_WHITELIST_ORIGINS you can define 
wildcards if you'd like to do the same thing as the proposed change 
, bit it's more explicit on 
your intentions for the behavior that you'd expect. 

*Match all subdomains example:*

CSRF_WHITELIST_ORIGINS = ['*.example.com']

OR

CSRF_WHITELIST_ORIGINS = ['.example.com']

*More explicit whitelisting:*

CSRF_WHITELIST_ORIGINS =[
'api.example.com',
'developers.example.com'
]

Security should always more explicit than implicit IMHO, but just to be 
clear, I am in big favor of a change as I need if for my sites and there 
are too many hacky solutions [1][2][3][4] that currently get around this by 
manually changing the *request.META['HTTP_REFERER']*.  Eeeek!

Troy

[1] 
https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py#L26
[2] https://groups.google.com/d/msg/django-developers/6kUiODYObnU/1wqxBqFP8UQJ
[3] http://zachsnow.com/#!/blog/2012/django-subdomains-csrf-and-https/
[4] http://bash-shell.net/blog/2014/aug/16/django-cors-and-csrf-validation/

On Thursday, March 19, 2015 at 10:50:05 AM UTC-6, Matt Robenolt wrote:
>
> Ticket and patch have been submitted regarding this:
>
> https://code.djangoproject.com/ticket/24496
> https://github.com/django/django/pull/4337
>
> Since this is related to CSRF and technically weakening the strictness of 
> the Referer check, Tim Graham suggested soliciting feedback here to get 
> more eyeballs and feedback.
>
> Please let me know if there's more context needed that can be added to the 
> ticket.
>
> My tl;dr is that Django should allow a Referer match across a subdomain, 
> and not exactly matching `request.get_host()` since cookies are allowed to 
> be set on subdomains as well. This is similar in vain to ALLOWED_HOSTS, 
> except Django would purely validate against the CSRF_COOKIE_DOMAIN.
>
> Thanks. <3
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c14fdc37-f8cb-4722-8a6b-d4dc3806713f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.