gerrit #7650 integrated into Tuleap 9.4.99.55

I'm surprised by the fact that Chrome does not fallback, it is not what the message say ("The referrer policy has been left unchanged.") and it is against the specification (the policy should not be changed if the header does not define a policy known by the browser).
Either way, I added the no-referrer-when-downgrade policy in the contribution that is currently under review so the issue is going to be solved.

Hi Thomas,
the only reason I left the last comment is because Chrome does NOT fall back to 'no-referrer-when-downgrade' as for now. It might become default in the future releases. I added 'no-referrer-when-downgrade' explicitly because I don't like to see errors in my Chrome console. With nginx: Referrer-Policy "no-referrer-when-downgrade, strict-origin, same-origin" my Chrome console stays clean.

Review gerrit #7650

Hum that's not really an issue since the browser will fallback to the default policy which is no-referrer-when-downgrade but after all explicit is better than implicit so we can specify it in our referrer policy.

For now Chrome needs something explicitly from the error list:

Failed to set referrer policy: The value 'strict-origin, same-origin' is not one of 'no-referrer', 'no-referrer-when-downgrade', 'origin', 'origin-when-cross-origin', or 'unsafe-url'. The referrer policy has been left unchanged.

For example, an explicit "no-referrer-when-downgrade" fallback will work:
Referrer-Policy: no-referrer-when-downgrade, strict-origin, same-origin

Ok, got it. This will prevent sending referrer from httpS to httP in all cases.

gerrit #7612 integrated into Tuleap 9.4.99.31

I confirm the need for request renaming to make it more precise, expressive and searchable.
I confirm the default referrer policy as the need for progressive fallbacks until browser support evolves.
I confirm the suggested referrer header acceptance on in 4 browsers as of today: Chrome, Firefox, Safari, Opera. [no errors thrown].

Review gerrit #7612

Ok, got it!

Yep supports of the referrer policy header is currently not great in Chrome. Firefox has full support starting the version 52.

I think we can make the following referrer policy the default in Tuleap:
Referrer-Policy: origin, strict-origin, same-origin

This way we reduce as much as we can what we expose to external sources with what the browser support. We do not need to use the *-when-cross-origin policies, Tuleap is fine with not having the full referrer.

Hi Thomas,
the same origin fallback fixes only Firefox, not Chrome.

Chrome gives following error:
Failed to set referrer policy: The value 'same-origin, strict-origin-when-cross-origin' is not one of 'no-referrer', 'no-referrer-when-downgrade', 'origin', 'origin-when-cross-origin', or 'unsafe-url'. The referrer policy has been left unchanged.

Hence, for now, I will stick with a "origin-when-cross-origin" fallback. The only difference to "same-origin" is that "same-origin" sends NO header from httpS to httP, but "origin-when-cross-origin" sends origin header not only between httpS, but ALSO from httpS to httP.

I will check header errors again after Tuleap 10 deployment. Hope "strict-origin-when-cross-origin" will be supported in all browsers then.

Ok, I consider this artifact as "closed" now.

Thanks for your help!

Hello,

Yep, I was wrong. I took the time to inspect the code a bit more to remember myself what Tuleap check and does not check.
As of today:
* anonymous user or user authenticated with a token: no check is done
* user authenticated with a cookie (typically this is the case when you use the agile dashboard): Tuleap verify the referer header, if the header is not present or set to a value we do not expect, the request is rejected

Tuleap does that as a way to mitigate CSRF attacks. On a side note we should probably update this check to also try to check the Origin header as recommended by the current best practices [1].

I did not yet test it how browser currently supports it but from I read in the referrer policy specification in our case the sanest and flexible option for us seems to set it to "same-origin". This way we respect the privacy of the Tuleap's users by avoiding the risk of leaking the referrer to outside sources. Setting the policy to no-referrer seems a bit much in our case. It prevents us to use classical CSRF prevention tricks and does really protect user's privacy. Indeed, we only check the referrer if we have authenticated the user so in a way we already are tracking him. How do you feel about that?

[1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Checking_the_Referer_Header

Hi Thomas,
Nope, I do not confirm your assumption "normally if no referrer header is sent you should not get an error."
After playing around I found that the errors are caused exactly when no referrer headers are sent:
add_header Referrer-Policy "no-referrer";

Attention: no headers sent != no headers specified. According to:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
If no header is specified, the default behaviour is as if a header:
add_header Referrer-Policy "no-referrer-when-downgrade ";
would exist, i.e. the header is always sent (same or cross-origin) from httpS to httpS, and never from httpS to httP

For me, the most secure working configuration now is the switch from:
add_header Referrer-Policy "no-referrer, strict-origin-when-cross-origin";
to
add_header Referrer-Policy "origin-when-cross-origin, strict-origin-when-cross-origin";

What happens now is instead of "no-referrer" policy for browsers that do not support "strict-origin-when-cross-origin",
the default fallback is now widely supported "origin-when-cross-origin".

CONCLUSIONS:
1) strict no referrer policy
add_header Referrer-Policy "no-referrer";
BRAKES backlog loading.
2) if referrer headers are not specified on the server = same as if
add_header Referrer-Policy "no-referrer-when-downgrade ";
was defined on the sever. Backlog LOADS.
3) secure referrer configuration:
add_header Referrer-Policy "origin-when-cross-origin, strict-origin-when-cross-origin";
Backlog LOADS.

Hi,

Thanks for the update.

I took a quick look at the code and normally if no referer header is sent you should not get an error. I need to test it to see what happen behind the scene.

Hi Thomas,
I tracked down the origin of this behaviour.
To reproduce the issue in Chrome and Firefox just add the following security header to nginx:

add_header Referrer-Policy "no-referrer, strict-origin-when-cross-origin";

When commenting out that header, Chrome & Firefox will load Backlog. Adding the security header back gives the above mentioned 4 GET errors.