Closed Bug 1737460 Opened 4 years ago Closed 2 years ago

Microsoft SSO broken

Categories

(Core :: Privacy: Anti-Tracking, defect, P3)

Product:
Core
Component:
Privacy: Anti-Tracking
Version:
Firefox 95
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox96 --- disabled

People

(Reporter: sfleiter, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

  • Open a company wiki page

Actual results:

Expected results:

  • Opening the wiki page in an authenticated fashion

This works on current Firefox Beta 94 with same Profile (--allow-downgrade used)

This does not work in Firefox Nightly 95.
Using safe-mode, disabling activity tracking or setting network.cookie.cookieBehavior to 3 does not fix the issue.

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Privacy: Anti-Tracking
Product: Firefox → Core

The bug does not happen in a new profile.
Still strange that the existing profile works fine in Firefox 94.

It works after removing all cookies and website data globally from settings.
I stll have a backup of the profile in case anybody is interested in investigating this.

Correction: After removing the data it works exactly once to then fail again when local wiki login session has run out.

Would you be able to provide the about:support?

Flags: needinfo?(stefan.fleiter)

I digged a bit more and the issue is caused by the setting network.cookie.sameSite.laxByDefault with a value of true which seems to be turned on as a Nightly Experiment.
Turning that of fixes login.

Flags: needinfo?(stefan.fleiter)
Severity: -- → S3
Priority: -- → P3

I digged a bit more and the issue is caused by the setting network.cookie.sameSite.laxByDefault with a value of true which seems to be turned on as a Nightly Experiment.
Turning that of fixes login.

Chrome has been shipping this feature for about a year now. If this setting breaks the site, how is it not broken in Chrome? Are we implementing the spec differently? Is the site sending us different responses? Is it a combination of the newer SameSite features with some tracking protection blocked content?

I have encountered this same bug with Firefox 96.0b2, and can confirm changing network.cookie.sameSite.laxByDefault to false is a workaround to the same problem.

Additionally, I tried in a Private Window with network.cookie.sameSite.laxByDefault set to true. The first time I attempt to authenticate, I am able to properly log into the company wiki. But if I explicitly log out to force a user/pass prompt again, at that point it fails to authenticate properly. One interesting part is that the second time I try to authenticate, my username is already listed, unlike the first time. I wonder if there's a certain amount of caching that is causing this bug.

If there is anything I can do to provide information helping to fix this, please reach out.
This is quite a serious issue with SSO.

This issue now made it to live ga version.
Users are reporting it repeatedly in our company now.

If you spoof a Chrome userAgent, does it work? In bug 1750152 I found that Microsoft was using incorrect cookie attributes with Firefox, but with Chrome and Edge they sent the correct "SameSite=None" attributes when they needed to.

You can spoof the useragent by opening "about:config", entering "general.useragent.override" in the search box, creating a string pref, and setting the value to "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4736.0 Safari/537.36". Remember to delete the pref when you're done testing.

If you're not comfortable mucking with prefs you can install an addon like the following:
https://addons.mozilla.org/en-US/firefox/addon/user-agent-string-switcher/

Is the "company wiki" page your own software and not Microsoft's? Could still be the same cause (not using the SameSite=None attribute on the cookies that need it), but then I'd expect Chrome and Edge to also fail. Chrome has shipped "laxByDefault" for over a year.

Flags: needinfo?(stefan.fleiter)

Thanks for your support Daniel!
I tried what you described and could not trigger it with the useragent override.

After that I removed the override, set network.cookie.sameSite.laxByDefault to true again and tried again to trigger it.
I tried it with existing profile and with new ones on Nightly, Beta and Release and did not manage to trigger it so far.

I will continue w/o the override and will report back if this happens again.
Keeping needinfo to report back on this in a week if this does not happen again.

PS: Company wiki is a company hosted Confluence.

I just hit this bug for the first time: SSO log in failed reproducibly on Jenkins. I first tried changing the user agent, as suggested by Daniel (I did not restart my browser after setting general.useragent.override, though). The SSO log in still failed. Then I removed general.useragent.override and set network.cookie.sameSite.laxByDefault to false (once again without restarting the browser). The SSO log in succeeded afterwards.

It happened again during Login to Wiki:

The Cookie "CkTst" got set same site policy to lax since it had no sameSite attribute.
That Cookie is from https://login.microsoftonline.com and written by the following code.

    writeWithExpiration: function (name, value, secure, expiresOn, domain, path, sameSite)
    {
        if (value === "")
        {
            CookieHelpers.remove(name, domain);
        }
        else
        {
            if (typeof value === "object")
            {
                value = ObjectHelpers.join(value, "&", "=");
            }

            var expiration = expiresOn ? (";expires=" + expiresOn) : "";
            var cookieDomain = domain ? (";domain=" + domain) : "";
            var cookiePath = path || "/";
            var secureContent = secure ? ";secure" : "";

            
            var sameSiteContent;
            if (!sameSite || sameSite.toLowerCase() === "none")
            {
                sameSiteContent = CookieHelpers.getDefaultSameSiteAttribute(secure);
            }
            else
            {
                sameSiteContent = ";SameSite=" + sameSite;
            }

            var cookieToWrite = StringHelpers.format("{0}={1}{2};path={3}{4}{5}{6}", name, value, cookieDomain, cookiePath, expiration, secureContent, sameSiteContent);

            document.cookie = cookieToWrite;
        }
    },

called by

    write: function (name, value, secure, persist, topLevel, addDomainPrefix, path, sameSite)
    {
        var prefix = addDomainPrefix ? "." : "";
        var parts = document.domain.split(".");

        if (topLevel)
        {
            parts.splice(0, Math.max(0, parts.length - 2));
        }

        var cookieDomain = prefix + parts.join(".");

        CookieHelpers.writeWithExpiration(name, value, secure, persist ? CookieHelpers.getPersistDate() : null, cookieDomain, path, sameSite);
    },

called by

var CookieHelpers = exports.Cookies =
{
    expireDate: "Thu, 30-Oct-1980 16:00:00 GMT",
    persistTTLDays: 390, 
    cookieSafeRegex: /^[\u0021\u0023-\u002B\u002D-\u003A\u003C-\u005B\u005D-\u007E]+$/,

    enabled: function ()
    {
        var date = new Date();
        var cookieValue = "G" + date.getTime();
        var cookieName = "CkTst";

        CookieHelpers.write(cookieName, cookieValue);
        var cookiesEnabled = !!CookieHelpers.getCookie(cookieName);
        CookieHelpers.remove(cookieName);

        return cookiesEnabled;
    },

    getCookie: function (name)
    {
        var cookies = StringHelpers.doubleSplit(document.cookie, ";", "=", false, StringHelpers.trim);

        if (cookies[name])
        {
            return cookies[name];
        }

        return null;
    },
Flags: needinfo?(stefan.fleiter)

Looking a bit more at this the "CkTst" cookie seems to be deleted again afterwards.
Hard to reason more.

I added the useragent override and that fixed it.
Sadly this works for now even with override removed and logout and login, so this is hard to track.

marking as disabled for fx96 since we set sameSite.laxByDefault and sameSite.noneRequiresSecure to false via a pref flip

status-firefox96: --- → disabled

We won't be shipping samesitelax by default, so all of this breakage bug can be closed: Bug 1617609

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.