Validate value of Referrer-Policy (instead of just existance)

[baknu]

See recommended values in test explanation.

[baknu]

Certain values are also required by DigiD since May 2020. See: "Update van de testaanpak DigiD-assessment 2.0" (https://www.norea.nl/download/?id=7851).

*Referrer-Policy*

Te configureren waarden: Gebruik de instelling ‘same-origin’, zodat de referrer-header alleen wordt meegestuurd bij verzoeken binnen het eigen domein. Dit voorkomt het lekken van privacygevoelige informatie bij omleiden naar externe domeinen. De striktere instelling ‘no-referrer’ kan ook worden gebruikt, zodat de referrer-header nooit wordt meegestuurd.

[baknu]

This should be implmented in a similar way as the "Validate CSP directives #325" change.

We need the following:

1. Validate Referrer-Policy values and check for no-referrer or same-origin that we consider good. Other values are considered as bad. Reference to relevant code: https://github.com/NLnetLabs/Internet.nl/blob/master/checks/tasks/http_headers.py#L605
2. The 'bad' verdict text (detail/web/appsecpriv/http-csp/verdict/bad_en.md) will be change into: "Your web server does not offer Referrer-Policy, or does offer Referrer-Policy with certain insecure and/or privacy-unfriendly settings."
3. Scoring (scoring.py) will not change. In case of bad (i.e. failing the test) we keep providing a warning (STATUS_NOTICE) which has no impact on %-score.

[sinteur]

Pull request https://github.com/NLnetLabs/Internet.nl/pull/516 - but it still needs a nice text in the translation files with a short explananation

[baknu]

See also #645 and #710

[baknu]

FAQ DigiD Assessment (v1.4 d.d. 8 november 2021) states:

Probleemschets Volgens de testaanpak 2.0 van juni 2020 is de verplichte minimale waarde “same-origin” en bij voorkeur de waarde “no-referrer”, leverancier kan deze header niet met de minimale waarde configureren.

Argumentatie Als de referrer policy header niet geconfigureerd is, wordt “by default” (no-referrer-when- downgrade) de volledige URL (incl. querystring) meegestuurd naar alle bestemmingen (ook cross- origin) met hetzelfde protocol. De Referrer policy header voorkomt het verspreiden van de querystrings en mede daarom is het opnemen van deze Referrer Policy header met de juiste voorgeschreven waarde een verplichting.

[WKobes]

@baknu it should be noted that that info is outdated. The default is now 'strict-origin-when-cross-origin'. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

[mxsasha]

Fix in #961. See the new unit tests

[atjn]

I think the implementation in #961 is wrong. If you can only distinguish between bad and good headers, then I think the strict-origin and strict-origin-when-cross-origin headers should also be considered good. This is also the recommendation that internet.nl currently gives if you run a website test:

Recommended policy values:

1. No sensitive data to third parties

   • no-referrer
   • same-origin

2. Sensitive data to third parties only via secure connections (HTTPS)

   • strict-origin
   • strict-origin-when-cross-origin (browsers' default policy according to current "Editor’s Draft")

I also think that the omission of a referrer-policy header should be good. All browsers now default to the strict-origin-when-cross-origin header, which is a good header. You can check the caniuse table to see that >95% of active browsers will default to the new secure header. (*Safari and Samsung Internet also default to it, despite what the table says. I am working on updating that info.)

As for an empty or misconfigured header, that is technically speaking also good because the browser should ignore it and default to a good header, but I can see the idea in marking it bad to make the developer aware that something is wrong.

[baknu]

@atjn Thanks for your feedback.

For possible test results see: https://en.internet.nl/faqs/report/ Note that this subtest currently does not weigh into the %-score. Therefore "bad" (❌) as a test result is not possible.

It might be better to handle it as follows. Will discuss this with the team. Let us know if you have any further feedback.

1. ✅ good: referer-policy with value no-referrer or same-origin --> message: "Your webserver has a referer-policy that requests browsers to not send potentially sensitive data (Referer header) to third parties."
2. ℹ️ informational: referer-policy with value strict-origin or strict-origin-when-cross-origin --> message: "Your webserver has a referer-policy that requests browsers to send potentially sensitive data (Referer header) to third parties but only when their website supports HTTPS."
3. ℹ️ informational: no referer-policy, thus defaulting to strict-origin-when-cross-origin --> message: "Your webserver does not have a referer-policy. Browsers will use the default setting and thus send potentially sensitive data (Referer header) to third parties but only when their website supports HTTPS."
4. ⚠️ warning: referrer-policy with other valid value (i.e. no-referrer-when-downgrade, origin-when-cross-origin, origin, and unsafe-url) --> message: "Your webserver has a referer-policy. However, its value is insuffienty secure. Therefore browsers are allowed to send potentially sensitive data (Referer header) to third parties also when their website supports only HTTP and not HTTPS.
5. ⚠️ warning: referrer-policy with invalid value, thus defaulting to strict-origin-when-cross-origin --> message: "Your webserver has a referer-policy. However, there seems to be a misconfiguration, because its value is invalid. Browsers will use the default and thus send potentially sensitive data (Referer header) to third parties but only when their website supports HTTPS."

[atjn]

@baknu thanks, that looks like a very good breakdown! I think the messages could be more helpful if they were more direct about what is wrong. Here is my suggestion, feel free to use the parts you agree with and discard the rest :)

1. :white_check_mark: good: Referrer-Policy with value no-referrer or same-origin --> message: "Your web server offers a Referrer-Policy that makes browsers omit the Referer header when navigating to third party websites. This eliminates any risk of sending sensitive information via the header."

2. :information_source: informational: Referrer-Policy with value strict-origin or strict-origin-when-cross-origin --> message: "Your web server offers a Referrer-Policy that makes browsers send your site origin when navigating to third party websites. For some sites, this could be sensitive information."

3. :information_source: informational: no Referrer-Policy, thus defaulting to strict-origin-when-cross-origin --> message: "Your web server does not offer a Referrer-Policy. Browsers will by default send your site origin when navigating to third party websites. For some sites, this could be sensitive information."

4. :warning: warning: Referrer-Policy with value origin or origin-when-cross-origin --> message: "Your web server offers a Referrer-Policy that makes browsers send your site origin when navigating to unencrypted third party websites. This information could leak to bad actors who eavesdrop on the connection."

5. :warning: warning: Referrer-Policy with value no-referrer-when-downgrade --> message: "Your web server offers a Referrer-Policy that makes browsers send the entire previous URL when navigating to third party websites. The URL can contain very sensitive information, such as a user ID."

6. :warning: warning: Referrer-Policy with value unsafe-url --> message: "Your web server offers a Referrer-Policy that makes browsers send the entire previous URL when navigating to third party websites, including unencrypted sites. The URL can contain very sensitive information, and it can leak to bad actors who eavesdrop on the connection."

7. :warning: warning: Referrer-Policy with invalid value, thus defaulting to strict-origin-when-cross-origin --> message: "Your web server offers a Referrer-Policy with an invalid value. Browsers will fall back to the default value and send your site origin when navigating to third party websites. For some sites, this could be sensitive information."

[baknu]

Looks good to me! @mxsasha could you check?

[mxsasha]

Digging into this code, we currently do not have support for distinguishing between good or bad, i.e. not three levels. Fixing that is a bigger task, so for now I'll count 2 and 3 as good as well.

[mxsasha]

Actually, even having separate messages for different results requires the same changes. So #961 now follows the options suggested by atjn's latest comment, with a different recommendation (INFO ℹ️ ) or error (NOTICE ⚠️ ) label for each bad value. Tests here as before. Will document the new labels later.

One thing still to address: how about multiple values? Say, Referrer-Policy: no-referrer-when-downgrade,same-origin? I couldn't find anything that said this was allowed, but perhaps I overlooked. Currently #961 treats this as an invalid value, i.e. NOTICE ⚠️ .

[WKobes]

@mxsasha sorry for the late reply but multiple directories seems to be valid. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#specify_a_fallback_policy

So the last policy in the list is the preferred policy (and should be tested upon)

[baknu]

Regarding multiple policies see also: https://www.w3.org/TR/referrer-policy/#unknown-policy-values

[baknu]

We should note in the test explanation that we do not check for delivery via (1) <meta> and (2) referrerpolicy content attribute. See the non-normative sections:

1. https://www.w3.org/TR/referrer-policy/#referrer-policy-delivery-meta
2. https://www.w3.org/TR/referrer-policy/#referrer-policy-delivery-referrer-attribute

We already make a similar remark in the test explanation with regard to CSP via <meta>.