1481749 - saml post is missing since Firefox 57 Quantum

Status: UNCONFIRMED

(Core :: Security: CAPS, defect)

Description

[p.lambert1]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.1.0) Gecko/20100101 Firefox/60.1.0
Build ID: 20180621121604

Steps to reproduce:

SAML authentication is not working anymore since Firefox 57 (tested with 56 (working), 57, 58, 59, 60esr, 60, 61) with typing the url to address bar or using a bookmark while localefilelinks policy is set.
The post SAML request is missing and therefore the SAML authentication is failing.

But there a two ways it is still working.
1. Using a link in our domain (e.g. enterprise.com) to the SAML counterpart (e.g. <a href=https://service.com/saml">SAML</a>) is working and
2. If i add the domain of the counterpart domain to "localfilelinks" (capability.policy.localfilelinks.sites("service.com")) policy, it is working also using the direct url and bookmark

Comment 1

[David Olah]

Hi!

Can you please give me the exact steps to reproduce this issue? With the information above, I am not able to reproduce it.

Comment 2

[p.lambert1]

I get the error when i clear the cache and then just use a bookmark to the website which is using the SAML authentication.

Comment 3

[David Olah]

Could you please attach a reduced test case? That way, I will be able to reproduce the issue exactly.

Thank you!

Comment 4

[p.lambert1]

Copy this URL into adress bar and check the traffic.
https://bosch.leanix.net/boschpflive
You will see a POST login request (certainly will fail because of access rights)
If you then clear cache, enable localfilelinks policy and open the URL again, it will fail

If you would now add "leanix.net" to the local file policy it would work again (see the POST login).

Comment 5

[David Olah]

Sorry, I still cannot reproduce this. I searched for localfilelinks policy and did not found it. Can you please give more exact steps, please?

Comment 6

[p.lambert1]

Here is the local file policy explained
http://kb.mozillazine.org/Security_Policies

You need following settings in prefs.js
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.localfilelinks.sites", "*domain*");

You may use the SAML-tracer Add-On to see in which case the saml POST is send and in which not, with the link above.

Additional Information
SAML2.0 can be used with initialisation either from service provider or from identity provider.
The error is only showing up while the authentication is initiated from service provider. If it is initiated from identity provider it is still working.

Guess: Maybe something about cross domain handling. Identity provider is normally out of your own domain, while the service provider is a "strange" domain.

Comment 7

[David Olah]

[e-mail], from comment 6 I would assume that we need a SAML2.0 service provider to reproduce this issue, which AFAIK we don't have. Also, the STR are still unclear to me at this point, therefore moving this issue to Core:Security for better traction.

Comment 8

[p.lambert1]

Additional problem description from one of our developer:

If an HTML form (<form>) is contained in an HTML page using the "post" method, Firefox will send a POST request when the form is submitted. This works even if the server of the action URL is not the same as the HTML page has worked out. It does not work if the port is different. Then the POST request is "downgraded" to the GET request and no more parameter values are transmitted.

Comment 9

[Andrew Overholt [:overholt]]

I'm not sure capability.policy.localfilelinks support still exists. Paolo said in https://bugzilla.mozilla.org/show_bug.cgi?id=1392615#c1 that add-ons supporting this would stop working in 57. Maybe Dan knows?

Maybe this is related to https://wiki.mozilla.org/WebExtensions/Filesystem?

Comment 10

[Daniel Veditz [:dveditz]]

The relevant code still appears to be in the tree:

https://searchfox.org/mozilla-central/rev/6d1ab84b4b39fbfb9505d4399857239bc15202ef/caps/nsScriptSecurityManager.cpp#1669

and we still have tests that appear to use it:

https://searchfox.org/mozilla-central/source/browser/base/content/test/tabs/browser_new_file_whitelisted_http_tab.js#21

(note "localfilelinks" is an arbitrary policy name copy/pasted from examples. Our test uses a different arbitrary policy name. the  important part is the ".checkloaduri.enabled")

Comment 11

[Mike Kaply [:mkaply] (PTO until Sept 14)]

I realize this is an old bug but it has come up in a separate context and I want to see if this is still an issue. (We're seeing another report of SAML POST not working)

p.lambert: Is https://bosch.leanix.net/boschpflive still showing this issue?

As far as localfilelinks goes, we moved that to an enterprise policy so it can be enabled there.

https://github.com/mozilla/policy-templates/blob/master/README.md#localfilelinks

But I'm really confused as to why a website would need that to do SAML.

Comment 12

[Mike Kaply [:mkaply] (PTO until Sept 14)]

From customer:

"The named website in the bugreport (leanix) is somehow working in the meantime. But we have a company internal system where authentication is done with 3rd party websites (using SAML), which still have issues until I add them to the localfilelink policy."

I'm not sure what I can do here without a way to recreate this externally.

I need to be able to debug.