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: 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

[Ramiro Morales]

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/CAO7PdF-WiQN_6FP0uW6P3%3D1bbQFtDy_FBRpYayxpKMByVVh-oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[André Tavares]

Hey,

I also came across this "issue" which I believe will become very common as 
architectures as the one described above are starting to be more common. 
Moreover, IMHO the overall way that Django handles CORS issues is 
sub-optimal... another issue that I keep bumping against is having multiple 
"Access-Control-Allow-Origin".

For the case described in this thread, I ended up adding the following code 
bellow to the "dispatch" of my custom API View that all API Handlers 
extend, before and after CSRF validation to ensure that, when CRSF checking 
is happening, things are as Django expects so that it doesn't break as you 
described.

@staticmethod
def _https_referer_replace(request):
"""
When https is enabled, django CSRF checking includes referer checking
which breaks when using CORS. This function updates the HTTP_REFERER
header to make sure it matches HTTP_HOST, provided that our cors logic
succeeds.

Based on snippet taken from:

https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py
"""
if settings.YAPI.get('XS_SHARING_REPLACE_HTTPS_REFERER') is True:
origin = request.META.get('HTTP_ORIGIN')
allowed_origins = settings.YAPI['XS_SHARING_ALLOWED_ORIGINS']
if request.is_secure() and origin and 'ORIGINAL_HTTP_REFERER' not in 
request.META:
if allowed_origins != '*' and origin not in allowed_origins:
return
try:
http_referer = request.META['HTTP_REFERER']
http_host = "https://%s/"; % request.META['HTTP_HOST']
request.META = request.META.copy()
request.META['ORIGINAL_HTTP_REFERER'] = http_referer
request.META['HTTP_REFERER'] = http_host
except KeyError:
pass

@staticmethod
def _https_referer_replace_reverse(request):
"""
Put the HTTP_REFERER back to its original value and delete the temporary 
storage.

Based on snippet taken from:

https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py
"""
if settings.YAPI.get('XS_SHARING_REPLACE_HTTPS_REFERER') is True and 
'ORIGINAL_HTTP_REFERER' in request.META:
http_referer = request.META['ORIGINAL_HTTP_REFERER']
request.META['HTTP_REFERER'] = http_referer
del request.META['ORIGINAL_HTTP_REFERER']




On Friday, 29 May 2015 06:33:12 UTC+1, Troy Grosfield wrote:
>
> 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 
>>> * 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'):
>>> [...

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 
>> * 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/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

[Josh Smeaton]

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 
> * 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/07797a9c-343f-4d30-8875-143aed56bd4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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.