V14.4.6 potential misleading advice in Referrer-Policy requirement

[elarlang]

Current requirement 14.4.6

14.4.6 Verify that a suitable "Referrer-Policy" header is included, such as "no-referrer" or "same-origin".

From this requirement one may interpret, that only no-referrer and same-origin are accepted values for Referrer-Policy, but this is not true. As there are quite many suitable values I think it's not smart to list all of them here.

So first recommendation is - to just strip them off:

14.4.6 Verify that a suitable "Referrer-Policy" header is included.

or to add something like "to avoid sensitive information leakage with Referer header" (and this is meaning, not actual wording for requirement).

[jmanico]

+1 strip them off so it's less confusing - Jim

On 10/25/20 8:31 AM, Elar Lang wrote: Current requirement 14.4.6 <https://github.com/OWASP/ASVS/blob/master/4.0/en/0x22-V14-Config.md#v144-http-security-headers-requirements> 14.4.6 Verify that a suitable "Referrer-Policy" header is included, such as "no-referrer" or "same-origin". From this requirement one may interpret, that only |no-referrer| and |same-origin| are accepted values for |Referrer-Policy|, but this is not true. As there are quite many suitable values I think it's not smart to list all of them here. So first recommendation is - to just strip them off: 14.4.6 Verify that a suitable "Referrer-Policy" header is included. or to add something like "to avoid sensitive information leakage with |Referer| header" (and this is meaning, not actual woring for requirement). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#861>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCJMFUWWH5L5UKBEE53SMRVI3ANCNFSM4S6QELRA>.

-- Jim Manico Manicode Security https://www.manicode.com

[elarlang]

Any other opinions or I move on (PR) with that?

[Sjord]

I think it is important to qualify what "suitable" means here. So I think it needs an additional sentence as to what the goal is of the referrer policy:

Verify that a suitable "Referrer-Policy" header is included, to avoid exposing sensitive information in the URL through the Referer header.

[jmanico]

I would agree I would like this requirement to give more advice on which of the settings of “Referrer-Policy” are reasonable and which ones are not, if possible.

…

-- Jim Manico @manicode

On Dec 7, 2020, at 4:34 AM, Sjoerd Langkemper ***@***.***> wrote:  I think it is important to qualify what "suitable" means here. So I think it needs an additional sentence as to what the goal is of the referrer policy: Verify that a suitable "Referrer-Policy" header is included, to avoid exposing sensitive information in the URL through the Referer header. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[elarlang]

If we want to have this longer description, then I would add "untrusted parties". Using @Sjord proposal as a base:

Verify that a suitable "Referrer-Policy" header is included, to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.

What is danger for me here - if we kind of propose to use no-referrer, it's bad for site own monitoring and analytics tools which needs Referer header information.

In case, when application domain name is "public", then I personally recommend to use strict-origin-when-cross-origin.

But I would like to avoid using any examples in requirement itself, otherwise we are back to the problem why I made this issue.

[Sjord]

Perhaps a referrer policy only makes sense for pages that load (third-party) resources. An API may not need a referrer policy at all. What a "suitable" referrer policy is, depends on what the site serves and whether there is sensitive information in the URL.

[elarlang]

Perhaps a referrer policy only makes sense for pages that load (third-party) resources. An API may not need a referrer policy at all. What a "suitable" referrer policy is, depends on what the site serves and whether there is sensitive information in the URL.

Additionally to loading resources from another pages (let's say classical HTML page), Referer is sent at least:

• on clicking links
• loading "resources by resources" - font files from css, something loaded by SVG etc.

"Loading resources" can be result of HTML injection as well - let's say attacker can put some hidden image samewhere and then can track, from what URL which user and when is loading it. Not sending Referer in this case does not fix the issue, but gives less information.

If you can wordsmith it, we can put it to the requirement, but at the same time I'm afraid it may miss some edge-cases with those restrictions.

[jmanico]

I prefer to keep this simple. I would like to stick with this and a little addition to state this is only needed for web clients. I think a PR is good now if you agree.

Verify that a suitable "Referrer-Policy" header is included for web based clients, to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.

[elarlang]

I think this proposal works better without "web based clients" - it's confusing (what it is exactly) and does not give anything extra.

Verify that a suitable "Referrer-Policy" header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.

[jmanico]

I agree.

I think this proposal works better without "web based clients" - it's confusing (what it is exactly) and does not give anything extra.

Verify that a suitable "Referrer-Policy" header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.

Agreed