Meta referrer="no-referrer" causes all posts to fail in Chrome #28299

sidot3291 · 2017-03-05T21:23:18Z

Steps to reproduce

Add this to your <head>:
<meta name="referrer" content="no-referrer">

Create a form with method='post' that points to a route on the same origin, go to the form in Google Chrome and click submit.

Expected behavior

I'm reporting this as an issue instead of a PR because I'm not quite sure of the expected behavior.

The request is failing because Chrome sets the Origin header to the string "null"

My instinct is that the request should succeed, since the valid_request_origin? method allows for the Origin header to be missing altogether:

rails/actionpack/lib/action_controller/metal/request_forgery_protection.rb

Line 400 in bc47815

def valid_request_origin? # :doc:

      def valid_request_origin? # :doc:
        if forgery_protection_origin_check
          # We accept blank origin headers because some user agents don't send it.
          request.origin.nil? || request.origin == request.base_url
        else
          true
        end
      end

However, I'm not an expert in CSRF and recognize the proper solution might be not to utilize this meta tag in the <head>

Actual behavior

The request fails during the valid_request_origin? check

System configuration

Rails version: 5.0.2

The text was updated successfully, but these errors were encountered:

Fixes rails#28299 Since Firefox doesn't send the Origin header when the meta tag is set but Chrome sends it with a "null" string, this change ensures Rails behaves consistently across browsers.

pixeltrix · 2017-03-06T16:02:33Z

Why would you set no-referrer on a page you were POST-ing back to yourself? Surely using same-origin would be a better choice? If the page with no-referrer on isn't under your control then isn't that the correct behavior?

sidot3291 · 2017-03-06T16:42:38Z

For reference:
https://w3c.github.io/webappsec-referrer-policy/

It looks like same-origin would solve my problem while also preventing the referrer from being sent cross-origin, which is my goal. Thanks for that idea.

That said, if I must set to same-origin, why does an omitted Origin header also pass the valid_request_origin? test? Is there a scenario where that exception is desired, and if so, are we confident that Chrome omits the header instead of sending through a "null" string?

Code looks like it was introduced here:
8578353

pixeltrix · 2017-03-06T16:56:32Z

why does an omitted Origin header also pass the valid_request_origin? test?

Don't know for sure but some scenarios could be posting from HTTP to HTTPS and legacy browsers.

I'm just loathe to special case values because the current version of a particular browser has a bug or behaves inconsistently - those kind of things tend to hang around in a framework for years (see #18255).

sidot3291 · 2017-03-06T21:12:53Z

This has turned into a rabbit hole for me, and I think I'm going to set forgery_protection_origin_check to false.

It turns out the Chrome has not implemented same-origin, and I don't see another option to prevent referrer/origin information from being sent externally.

There is a lot of inconsistency across browsers in their current state on macOS:

Chrome POST to same origin:
default: sends Origin according to spec
no-referrer set: sends Origin: "null"

Firefox POST to same origin:
default: does not send Origin
no-referrer set: does not send Origin

Safari POST to same origin:
default: sends Origin according to spec
no-referrer set: sends Origin same as default case

I see an argument that we don't want to allow "null" since setting "no-referrer" would then represent a reasonable approach for attackers to undermine this check for cross-origin requests.

However, I also worry that working with Origin is like trying to prevent CSRF with the Referer header all over again. Tokens still feel like the gold standard, and with those still in use, I'm not sure which attack vector the forgery_protection_origin_check realistically protects against, especially given such inconsistency across browsers.

sgrif · 2017-10-09T19:36:42Z

So after doing further digging, this is not a bug. It could be considered a bug in Firefox that it isn't sending this value, (see https://bugzilla.mozilla.org/show_bug.cgi?id=446344), but basically the reason this is happening is due to a rather vague line in the Origin spec:

Whenever a user agent issues an HTTP request from a "privacy-sensitive" context, the user agent MUST send the value "null" in the Origin header field.

It's likely that most people setting the no-referrer value probably want strict-same-origin instead. If they don't, they'll need to change the value of the forgery_protection_origin_check to false and opt out of this. Rails is currently doing the right thing as described in the original proposal of the Origin header for CSRF protection

If the Origin header is present, the server must reject any requests whose Origin header contains an undesired value (including null).

phillycheeze · 2017-10-09T21:30:23Z

@sgrif I think there should be more discussion on this issue. As the post you provided, there are two conflicting entries in the specs.

As it stands right now, the two specs have a conflict. So the solution is that I cannot set that header? Browsers are correctly adhering to spec by setting it to "null" (which is the newer spec from what I am seeing).

The second spec you linked is a proposal from Stanford. Did this make it into an actual specification? If so, can you link it? Even then, we should adopt to the newer spec and simply whitelist the "null" value. Or at the very least, continue the debate. As it stands, Rails simply does not work with a valid header value.

sgrif · 2017-10-09T21:37:29Z

The HTTP specification of the request header does not specify server behavior, because it's not relevant to the intent. The paper I linked to is the intent behind the header being specified. There's no "newer" or "older" conflict here.

phillycheeze · 2017-10-09T21:38:03Z

The privacy-sensitive context in the specification also goes on to say that the interpretation is up to the application/browser. So null string values could get added later on for other header values (or any other changes that we can't predict).

I read the propsal and understand why the Origin header exists. But the proposal says null values meaning true null, not the string null. It says to prevent non-support browsers from being accepted, which won't happen in this string approach.

sgrif · 2017-10-09T21:41:31Z

But the proposal says null values meaning true null, not the string null

There is no difference in HTTP. The only values are strings. You cannot set a "true null" for a header

phillycheeze · 2017-10-09T21:46:44Z

You're correct. My apologies.

There is still a gap here. As the header gains more attention and privacy concerns increase, this will only be an increasing challenge, correct?

sgrif · 2017-10-09T21:56:37Z

It will, which is why on the corresponding PR I asked that we instead raise an error message that specifically explains the issue to the person receiving the error. I suspect the vast majority of people using no-referrer would be fine with strict-same-origin. Those that aren't will need to opt out of origin checking for CSRF. We can teach that in the error message, but after spending a hefty chunk of the day researching this and discussing it with people involved, I'm convinced that the current behavior of Rails is the correct one.

phillycheeze · 2017-10-09T22:04:12Z

Yes, I definitely agree with you. Thanks for all of your help and dedicating time to this!

sidot3291 mentioned this issue Mar 6, 2017

Accept requests sent with no-referrer in Chrome #28304

Closed

maclover7 added actionpack needs work attached PR labels Mar 6, 2017

This was referenced Oct 9, 2017

Fix issue #30658 by checking explicitly for 'null' referrer #30780

Merged

InvalidAuthenticityToken raised when setting Referrer-Policy: no-referrer; header #30658

Closed

sgrif closed this as completed Oct 9, 2017

ykzts mentioned this issue Jan 26, 2018

Sometimes logging in is a little bit buggy mastodon/mastodon#6366

Closed

2 tasks

baptx mentioned this issue Jul 7, 2018

Referrer-Policy header: "strict-same-origin" value w3c/webappsec-referrer-policy#114

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Meta referrer="no-referrer" causes all posts to fail in Chrome #28299

Meta referrer="no-referrer" causes all posts to fail in Chrome #28299

sidot3291 commented Mar 5, 2017 •

edited

Loading

pixeltrix commented Mar 6, 2017

sidot3291 commented Mar 6, 2017

pixeltrix commented Mar 6, 2017

sidot3291 commented Mar 6, 2017

sgrif commented Oct 9, 2017

phillycheeze commented Oct 9, 2017

sgrif commented Oct 9, 2017 •

edited

Loading

phillycheeze commented Oct 9, 2017

sgrif commented Oct 9, 2017

phillycheeze commented Oct 9, 2017

sgrif commented Oct 9, 2017

phillycheeze commented Oct 9, 2017

Meta referrer="no-referrer" causes all posts to fail in Chrome #28299

Meta referrer="no-referrer" causes all posts to fail in Chrome #28299

Comments

sidot3291 commented Mar 5, 2017 • edited Loading

Steps to reproduce

Expected behavior

Actual behavior

System configuration

pixeltrix commented Mar 6, 2017

sidot3291 commented Mar 6, 2017

pixeltrix commented Mar 6, 2017

sidot3291 commented Mar 6, 2017

sgrif commented Oct 9, 2017

phillycheeze commented Oct 9, 2017

sgrif commented Oct 9, 2017 • edited Loading

phillycheeze commented Oct 9, 2017

sgrif commented Oct 9, 2017

phillycheeze commented Oct 9, 2017

sgrif commented Oct 9, 2017

phillycheeze commented Oct 9, 2017

sidot3291 commented Mar 5, 2017 •

edited

Loading

sgrif commented Oct 9, 2017 •

edited

Loading