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?

[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?

[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.

[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']

[Ramiro Morales]

On Fri, May 29, 2015 at 12:41 AM, Troy Grosfield
<troy.gr...@gmail.com> 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

[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

[Troy Grosfield]

This same issue is being discussed here as well:

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