Card payment no longer works with PM

[Kris_88]

Looks like FF just started wholesale ignoring that and always allowing it, contrary to the spec.

It seems to me that this is the opposite - a tightening of policy. No?
Okay... I'll dig into this some more, a little later.

[Moonchild]

It seems to me that this is the opposite - a tightening of policy. No?

No, they added a pref for "relaxed" which is always true (i.e. ignore the restriction) except in their test suite.

[Kris_88]

First, they made a default value for the referrer policy.
network.http.referer.defaultPolicy
https://wiki.mozilla.org/Security/Referrer
For example, the default value is 3 (no-referrer-when-downgrade) for FF65 and 2 (strict-origin-when-cross-origin) for FF105.

Currently, the default referrer policy is "strict-origin-when-cross-origin".
https://w3c.github.io/webappsec-referre ... rrerpolicy
https://developer.mozilla.org/en-US/doc ... rer-Policy
For other browsers:
https://github.com/privacycg/proposals/issues/13

Sites may try to set a policy that is more or less strict than the default policy.
However, some browsers may not allow sites to set a policy that is less restrictive than the default policy.
In Firefox, this browser behavior is controlled by a preference group "network.http.referer.disallowCrossSiteRelaxingDefault".
https://groups.google.com/a/mozilla.org ... Gbc5I4wd6U
(The way I understand it is that the browser ignores the site's attempts to set a less restrictive policy when disallowCrossSiteRelaxingDefault == true. Of course, we can look in the code to see what exactly they do with this preference...)

https://support.mozilla.org/en-US/questions/1389812

Code: Select all

Examples of those prefs & their normal values:
network.http.sendRefererHeader         2
network.http.referer.XOriginPolicy	0	
network.http.referer.XOriginTrimmingPolicy	0	
network.http.referer.defaultPolicy	2	
network.http.referer.defaultPolicy.pbmode	2	
network.http.referer.defaultPolicy.trackers	2	
network.http.referer.defaultPolicy.trackers.pbmode	2	
network.http.referer.disallowCrossSiteRelaxingDefault	true	
network.http.referer.disallowCrossSiteRelaxingDefault.pbmode	true	
network.http.referer.disallowCrossSiteRelaxingDefault.pbmode.top_navigation	true	
network.http.referer.disallowCrossSiteRelaxingDefault.top_navigation	false	
network.http.referer.hideOnionSource	false	
network.http.referer.referrerLengthLimit	4096	
network.http.referer.spoofSource	        false	
network.http.referer.trimmingPolicy	0

[Kris_88]

By the way, in UXP the default referer policy is "REFERRER_POLICY_NO_REFERRER_WHEN_DOWNGRADE".
UXP: HttpBaseChannel.cpp: mReferrerPolicy(REFERRER_POLICY_NO_REFERRER_WHEN_DOWNGRADE)

And this function should add a referer header:
UXP: HttpBaseChannel.cpp: HttpBaseChannel::SetReferrerWithPolicy(nsIURI *referrer, uint32_t referrerPolicy)

But this function is simply not called for the preflight requests in UXP (it is called in FF65).

UXP: nsCORSListenerProxy.cpp

Code: Select all

nsresult nsCORSListenerProxy::StartCORSPreflight(
  ...

  rv = preflightChannel->SetNotificationCallbacks(preflightListener);
  NS_ENSURE_SUCCESS(rv, rv);

  // Start preflight
  rv = preflightChannel->AsyncOpen2(preflightListener);
  NS_ENSURE_SUCCESS(rv, rv);

  // Return newly created preflight channel
  preflightChannel.forget(aPreflightChannel);

  return NS_OK;

FF65: nsCORSListenerProxy.cpp

Code: Select all

nsresult nsCORSListenerProxy::StartCORSPreflight(
  ...

  rv = preflightChannel->SetNotificationCallbacks(preflightListener);
  NS_ENSURE_SUCCESS(rv, rv);

  // Per https://fetch.spec.whatwg.org/#cors-preflight-fetch step 1, the
  // request's referrer and referrer policy should match the original request.
  uint32_t referrerPolicy = nsIHttpChannel::REFERRER_POLICY_UNSET;
  rv = reqCh->GetReferrerPolicy(&referrerPolicy);
  NS_ENSURE_SUCCESS(rv, rv);
  nsCOMPtr<nsIURI> requestReferrerURI;
  rv = reqCh->GetReferrer(getter_AddRefs(requestReferrerURI));
  NS_ENSURE_SUCCESS(rv, rv);
  rv = preCh->SetReferrerWithPolicy(requestReferrerURI, referrerPolicy);
  NS_ENSURE_SUCCESS(rv, rv);

  // Start preflight
  rv = preflightChannel->AsyncOpen2(preflightListener);
  NS_ENSURE_SUCCESS(rv, rv);

  // Return newly created preflight channel
  preflightChannel.forget(aPreflightChannel);

  return NS_OK;
}

[LuftWafflePilot]

Wow, I got a response from Comgate. They said something along the lines of "fixing the missing headers in future", whatever that means. I expected either nothing or the usual "download a supported browser".

[Moonchild]

Sites may try to set a policy that is more or less strict than the default policy.
However, some browsers may not allow sites to set a policy that is less restrictive than the default policy.

So, effectively, browser implementations make the entire referrer part of the CORS spec totally moot. Great.

But this function is simply not called for the preflight requests in UXP (it is called in FF65).

Well we should just be able to add this line, right, so it gets added to preflight? I mean, if that's what's expected by the web. And we can continue to do the right thing otherwise which is honor headers (contrary to other browsers)...

[Kris_88]

I think it would be good to add a preference "network.http.referer.defaultPolicy" and add the "referer" header to preflight requests. But I don’t have the opportunity to build from source right now, so I don’t think I can help. In any case, it's up to you.

[Kris_88]

@Moonchild

So what about this problem?
This can be very disruptive for many sites that expect a "referer" header.
And, no, there is no RFC violation here, because the page (https://pay2.comgate.cz/status/5HAM-TUOL-T4GR) explicitly specified the "referrer-policy" header as "unsafe-url".

[Moonchild]

Our CSP code has been updated on the master branch. Not sure if that addresses this particular problem (not tested yet) but I think it should.

[Kris_88]

Not sure if that addresses this particular problem

Probably not.
https://repo.palemoon.org/MoonchildProd ... .cpp#L1530

[Moonchild]

Right-o. thanks for the ping, I'll look at sliding these changes in.

[Moonchild]

And, no, there is no RFC violation here, because the page (https://pay2.comgate.cz/status/5HAM-TUOL-T4GR) explicitly specified the "referrer-policy" header as "unsafe-url".

That's irrelevant because an OPTIONS request is sent as a preflight BEFORE the GET is sent, so that header will not be parsed (it's not in a preflight). as stated before those requests are by their nature insecure. And pale Moon applies the default, as a result, which is not "unsafe-url", unlike what Chrome and FF apparently do, unconditionally, with that added code.
But if that's the way it's done in all other browsers then we're just going to have to follow that behaviour.

[Kris_88]

That's irrelevant because an OPTIONS request is sent as a preflight BEFORE the GET is sent, so that header will not be parsed (it's not in a preflight).

Of course, the OPTIONS request is sent before the GET request for the resource:
https://payments.comgate.cz/client/inst ... -TUOL-T4GR

But I'm talking about something else. The ROOT page (https://pay2.comgate.cz/status/5HAM-TUOL-T4GR) from which a request to a resource (https://payments.comgate.cz/client/inst ... -TUOL-T4GR) is sent, has already set referrer-policy = "unsafe-url". And this policy must be applied to requests that the ROOT page generates.

U12.png

[Moonchild]

I see. Sorry for being a bit dense on this. It still seems that this is stated paradoxically in both specs, but either way Issue #2451 (UXP) is there and will be addressed before v33 (I'm pretty sure I can get this done before the weekend, even)

[Kris_88]

Thank you!