@Findus23 opened this Pull Request on May 25th 2019 Member

See also #13479, https://github.com/matomo-org/matomo/issues/13204 and https://github.com/matomo-org/matomo/pull/12780

strict-origin only sends a header to the same domain AND origin (so only to HTTPS if Matomo is HTTPS) and no Referer to all other origins.

This does not work in the email report as it seems to be setting headers somewhere else

@diosmosis commented on June 16th 2019 Member

Is there a reason to use strict-origin over no-referrer? (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Directives)

@Findus23 commented on June 16th 2019 Member

I haven’t checked if there aren’t any parts of Matomo that require a referrer (maybe nonce check)

Lukas

Am 17.06.2019 um 00:39 schrieb diosmosis <notifications@github.com>:

Is there a reason to use strict-origin over no-referrer? (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Directives)


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@diosmosis commented on June 16th 2019 Member

I see, looks like we do use it in some internal requests. Reading the docs more, I think what we want is same-origin, that should prevent it from going to any other domains, and from the examples it looks like the protocol must be the same too. Though the docs aren't really specific about that. I'm not sure if it's really a security risk though.

Only thing I might be worried about is the SAML plugin which uses quite a few redirects when logging a user in. Would need to test that still works and possibly allow some requests to omit the referrer policy.

@Findus23 commented on June 16th 2019 Member

Same-origin sounds like it has the potential to ne less secure than the default as it seems to enable referrers from https to http. That’s why I would go with strict-origin.

Lukas

Am 17.06.2019 um 00:51 schrieb diosmosis <notifications@github.com>:

I see, looks like we do use it in some internal requests. Reading the docs more, I think what we want is same-origin, that should prevent it from going to any other domains, and from the examples it looks like the protocol must be the same too. Though the docs aren't really specific about that. I'm not sure if it's really a security risk though.

Only thing I might be worried about is the SAML plugin which uses quite a few redirects when logging a user in. Would need to test that still works and possibly allow some requests to omit the referrer policy.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@diosmosis commented on June 16th 2019 Member

But if it only sends the referrer to the same matomo instance, and not to any other domain, wouldn't it be more secure than strict-origin? Or am I missing something? Note: in the examples on MDN, the domain is sent on cross-origin requests w/ strict-origin.

@Findus23 commented on June 17th 2019 Member

I just checked again and compared with https://scotthelme.co.uk/a-new-security-header-referrer-policy/ and you are right.
The origin in strict-origin refers to only sending the origin as referrer and not to being limited to the same origin.
same-origin is what we want, sending a referrer to the same origin (domain and protocoll) and no referrer otherwise.

@diosmosis commented on June 17th 2019 Member

It took me a bit to realize as well, there's definitely a naming issue there.

@tsteur commented on July 5th 2019 Member

image

tested it... it then sends only the domain as referrer instead of the full URL.
This breaks eg redirectToReferrer feature etc. Is there maybe a different way? Or maybe it's easier to go through most links and check there is noreferrer set as an attribute? Especially in the dataTable? The dataTable links might be enough?

@diosmosis commented on July 8th 2019 Member

@Findus23 will you have time to update this PR?

@Findus23 commented on July 13th 2019 Member

Okay, after another huge confusion I have now updated the PR

This Pull Request was closed on July 14th 2019
Powered by GitHub Issue Mirror