Redmine

It is not a perfect solution because some browsers such as Edge 18 and Safari on iOS 12 don't support "origin-when-crossorigin" value for "referrer" meta tag.
https://caniuse.com/#search=referer

However, adding the meta tag is effective to mitigate the security risk if users in the organization use Chrome, Firefox, or Safari.

Index: app/views/layouts/base.html.erb
===================================================================
--- app/views/layouts/base.html.erb    (revision 17495)
+++ app/views/layouts/base.html.erb    (working copy)
@@ -7,6 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
 <meta name="description" content="<%= Redmine::Info.app_name %>" />
 <meta name="keywords" content="issue,bug,tracker" />
+<meta name="referrer" content="origin-when-crossorigin" />
 <%= csrf_meta_tag %>
 <%= favicon %>
 <%= stylesheet_link_tag 'jquery/jquery-ui-1.11.0', 'application', 'responsive', :media => 'all' %>

Maybe adding Referrer-Policy header is preferable rather than adding a meta-tag for the following reasons.

• We can ensure that the header is always set
• Sysadmins can easily override the header by configuring web servers if necessary

diff --git a/config/application.rb b/config/application.rb
index d77d37e70..3e014f480 100644
--- a/config/application.rb
+++ b/config/application.rb
@@ -53,6 +53,8 @@ module RedmineApp
     # Sets the Content-Length header on responses with fixed-length bodies
     config.middleware.insert_after Rack::Sendfile, Rack::ContentLength

+    config.action_dispatch.default_headers['Referrer-Policy'] = 'origin-when-cross-origin'
+
     # Verify validity of user sessions
     config.redmine_verify_sessions = true

This seems to be a sensible improvement. It does not impact the behavior for users on IE/Edge, but it improves privacy for users of Chrome, Firefox, Safari.

I also agree, that using an HTTP header is the better option.

However, I am not sure whether same-origin or origin-when-cross-origin would be the better default.

The most secure variant would probably be strict-origin-when-cross-origin which seems to be supported by the same current set of commonly used browsers which support origin-when-cross-origin. Compared to the shorter option, the strict one ensures that we don't sent any referrer from a secure page to an unsecure page, similar to the default no-referrer-when-downgrade.

As such, I vote for strict-origin-when-cross-origin. That way, we can still leverage the use of referrers locally (e.g. through log analysis) but don't leak potentially private data to external sites.

If we also want to specifically support IE, we should use origin. However, this would impact most local log analyzer software people might use on their Redmine installations as user flows can not be followed anymore. Thus, I think it's a reasonable tradeoff to use origin-when-cross-origin with most users and to accept the potential leaks for IE/Edge users (until Microsoft and Apple implement the current spec in Edge and Safari/iOS).

I'm with Maeda-san and Greger to use a header instead of a meta tag.

Using Referrer-Policy HTTP header is a great idea.

Holger Just wrote:

If we also want to specifically support IE, we should use origin. However, this would impact most local log analyzer software people might use on their Redmine installations as user flows can not be followed anymore. Thus, I think it's a reasonable tradeoff to use origin-when-cross-origin with most users and to accept the potential leaks for IE/Edge users (until Microsoft and Apple implement the current spec in Edge and Safari/iOS).

Whatever you decide to use in the end, please don't use origin, since it would not only affect logs, but Redmine itself relies on the Referer header, whenever it uses redirect :back.

When using origin, this would result in a redirect to the main page. The fallback specified for redirect_back_or_default would not be used, since a Referer header is present. This would result in a serious negative impact on the user flow.

Hi,

If you look at HTTP Headers, could you have a look to #29405

Best regards

Holger Just wrote:

The most secure variant would probably be strict-origin-when-cross-origin which seems to be supported by the same current set of commonly used browsers which support origin-when-cross-origin. Compared to the shorter option, the strict one ensures that we don't sent any referrer from a secure page to an unsecure page, similar to the default no-referrer-when-downgrade.

Thank you for the detailed explanation. Now I think strict-origin-when-cross-origin is the best. We should not use looser option than default no-referrer-when-downgrade.

Index: config/application.rb
===================================================================
--- config/application.rb    (revision 17559)
+++ config/application.rb    (working copy)
@@ -53,6 +53,10 @@
     # Sets the Content-Length header on responses with fixed-length bodies
     config.middleware.insert_after Rack::Sendfile, Rack::ContentLength

+    # Strip path information in the Referer header to prevent sending
+    # private data to external sites
+    config.action_dispatch.default_headers['Referrer-Policy'] = 'strict-origin-when-cross-origin'
+
     # Verify validity of user sessions
     config.redmine_verify_sessions = true

It looks like strict-origin-when-cross-origin is already set by Rails 5 default settings, see https://guides.rubyonrails.org/security.html#content-security-policy