Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

Some browsers already implement the Referrer Policy draft, which gives the developer more control over the referer HTTP header sent by the browser. Sometimes is useful to set a more private policy, like Origin When Cross-Origin, to prevent disclosing sensitive URL info to a third-party, like a password reset token for example.

But one can't just set the policy to Origin When Cross-Origin, because it will break on Safari, since Safari doesn't adhere to newest spec and defaults to no-referrer, which breaks form submits on HTTPS because of Django strict referrer check. Also, I can't imagine now why, but some developer might want to disable referer header altogether, and can easily do so by setting policy to No Referrer. See the rationale behind strict referrer check and the code.

Maybe Django shouldn't do do strict referrer check anymore?

It's very strange to change a HTML meta tag and break everything. And break in staging specifically, because this happens only on secure requests.

If Django still needs the strict referrer check, maybe a better error message should be implemented.

[Collin Anderson]

Seems to me we could ignore the referrer if we get a valid same-domain Origin header.

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/3dcbec32-b180-4cba-9276-731946fdccf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Flávio Junior]

That won't solve the problem.

If you set policy to No Referrer and make a request to the same origin, Chrome sets Origin to "null", Firefox doesn't set the header and Safari sets the correct origin.

[Florian Apolloner]

On Wednesday, December 2, 2015 at 7:37:30 PM UTC+1, Flávio Junior wrote:

If Django still needs the strict referrer check, maybe a better error message should be implemented.

I do not see any reason why it would not need it anymore. Django needs to ensure that the request came from a "trusted origin", therefore we still need it.

[Flávio Junior]

Florian, then Django will have to keep this limitation: can't use a global no-referrer policy on HTTPS because of strict referrer check. Correct? Should I create an issue to keep this logged?

[Flávio Junior]

Found a issue that already discusses this: https://code.djangoproject.com/ticket/16870#comment:10

[Tim Graham]

Flávio, thanks -- since you seem to have a good understanding of the limitation, could you submit a documentation patch (or even just provide some draft text here)?

[Collin Anderson]

Also, if we checked the origin header, would it allow us to at least support the "Origin When Cross-Origin" policy in all browsers? (Use the Origin header for Safari and the referrer for all of the other browsers?)

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/c0ce17a5-3f0e-4218-a2c8-cecf7da07fb9%40googlegroups.com.

[Flávio Junior]

Hi Collin,

Firefox doesn't include Origin header on same-origin POST/PUT/DELETE requests. I just tested it and this SO answer says the same.

But yes, checking both Origin and Referer headers would help giving support Origin When Cross-Origin.

I can create a ticket suggesting Django to check Origin header before checking Referer. Or do you want to create that Collin?

[Jon Dufresne]

On Wed, Dec 2, 2015 at 10:29 AM, Flávio Junior <flavio...@gmail.com> wrote:
> Also, I can't imagine now why, but some
> developer might want to disable referer header altogether, and can easily do
> so by setting policy to No Referrer.

Why is it unimaginable that I may want to maximize privacy for my
users? The domain my users are coming from is between me and my users.
If CSRF would work securely without any referer header (and not leak
the same data some other way), I would choose to disable it entirely.
Often the domain is enough to leak what kind of data a user was
reading or interacting with. For example, what might one assume
(rightly or wrongly) if the referer header was
"https://wikileaks.org"?

[Flávio Junior]

Yes Jon, makes sense, sorry for missing that.

The only HTML-only solution I see for this is to manually add rel="noreferrer" to all external links on my webapp, which is a pain.

With extra backend code, one might also implement something similar to https://anon.click/ to prevent referrer leaking.

So the problem with Django strict referrer check is deeper. It introduces complexity to make secure webapps that don't leak referrer info.

PS: don't know if anon.click is safe or trustable.

[Florian Apolloner]

On Friday, December 4, 2015 at 8:03:45 PM UTC+1, Flávio Junior wrote:

I can create a ticket suggesting Django to check Origin header before checking Referer. Or do you want to create that Collin?

I think Firxfox does not send the origin header ever yet, do you have any docs on that (Aside from CORS with Ajax from the looks of it)

[Collin Anderson]

Basically, the origin check would only be useful for safari (in this case). Everywhere else we'd still need to rely on the referrer header.

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/1cb9d411-8247-4e93-8120-5d043869c001%40googlegroups.com.

[Flávio Junior]

After two years, made a PR for this during PyCon sprints: https://github.com/django/django/pull/8546 

🍾