Set "Referrer-Policy" header to prevent leaking secret tokens in URLs

[jenlampton]

Problem/Motivation

Drupal has a few URL paths that can contain sensitive information, which in some cases allows account take overs. For example, a password reset URL (ex: https://example.com/user/reset/1/1547937498/Y9AkxAm1sFba85b74eJgSfNoSD22877Px6IbtFITYUw) can be reused as long as the user does not proceed with the login.

Browsers send URLs of the referring pages when requesting assets such as images, fonts, and CSS/JS files. If an attacker controls any of the assets used in a password reset URL, they can log all incoming requests, and use the URLs sent by the browsers to take over the user accounts. Although the attack surface is reduced due to the way tokens are invalidated on login, these URLs are reusable provided the attacker races the real user to go through the password reset URL.

HTTP referrer-policy header allows web sites to indicate whether the browser should send along the current URL of the page when requesting web page assets. This is a fairly new HTTP header, but is supported by all current browsers (i.e no Edge support).

Proposed resolution

The suggested resolution seems a fairly easy one, that core send this header on sensitive pages and any other sensitive pages (such as ures password reset; theme switch URL, using similar token) to emit a Referrer-Policy: strict-origin as a safeguard.

Remaining tasks

1. Agree on the method of adding this to core.
2. Collect the URLs that need to be addressed.
3. Add test coverage.

Alternative solutions

• the Security Kit module already has an option to output the Referrer-Policy header.

Related drupal issue

https://www.drupal.org/project/drupal/issues/3027122

Relevant questions from the Drupal issue

1. does it make sense to add it to the core .htaccess as a stop-gap until it's added in PHP?

[laryn]

Since it's referenced I'll note there is a Backdrop version of Security Kit:

• https://github.com/backdrop-contrib/seckit