1599368 - SameSite strict cookies not sent when browsing from Firefox default home page

Status: VERIFIED FIXED

(Firefox :: New Tab Page, defect, P1)

Description

[frederic.delaporte]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Navigate enough times a website having a samesite strict cookie to have it linked from your local Firefox default home page.
Open a new tab, use the link to that site from your local firefox default home page to open the iste

Actual results:

The samesite strict cookies are not sent

Expected results:

The samesite strict cookies should have been sent IMO.

Since that is a link locally generated for the user browser by the browser itself from its history of browsing, it should not be considered as a cross-origin link. (Even though I guess technically this Firefox default home page is implemented as a local dynamically generated html page.)

Comment 1

[frederic.delaporte]

This may cause web site implementers to drop SameSite Strict. I have recently added it to a site I have to maintain for better protection against CSRF, but this bug causes issue to its users. This site has a "remember me" option which does no more work when these users just use their links from their Firefox home page.
They may accept using a bookmark instead, which currently works, and the few who have complain about this currently accept this workaround. But I am not in a position to force everyone to accept this workaround.

Furthermore, I was thinking of a technical workaround implemented by the site itself, refreshing the page if it detect through some ajax request it actually has the cookie. But it seems https://bugzilla.mozilla.org/show_bug.cgi?id=1459321 will prevent this from working.

There is is also https://bugzilla.mozilla.org/show_bug.cgi?id=1573860 which looks alike my report, but personally, I am not able of reproducing that one, neither from the location bar (is that the url as I believe, or something else?) or a bookmark.

Comment 2

[Kershaw Chang [:kershaw]]

Hi Reporter,
Is it possible to provide the public website, so we can use it to test and reproduce this issue?

Comment 3

[frederic.delaporte]

Hi, this page provided for #1573860 should be more convenient for testing.

https://shhnjk.azurewebsites.net/SameSite.php

The web site on which I work is publicly exposed, but not referenced as it is a backoffice. And without an account, which are given only to employees, it is not possible to have the persisted auth cookie.
Is it ok for you to use the above test page provided for another bug?

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:valentin, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Attachment: nsHttp_cookie_log.txt

MOZ_LOG=sync,timestamp,nsHttp:5,cookie:5 firefox -P new -no-remote

Second load of GET /SameSite.php reproduces the bug
Third load of GET /SameSite.php is opening it in a new tab.

I don't see exactly what's wrong here.

Junior, could you also take a look if you can reproduce and/or spot the problem?
Christoph, any idea why a load triggered from about:newtab would not load the strict cookie?

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Valentin Gosu [:valentin] (he/him) [PTO until Jan 6th] from comment #5)

Christoph, any idea why a load triggered from about:newtab would not load the strict cookie?

I haven't tested myself, but most likely about:newtab is a content privileged page so the principal/uri is about:newtab and hence the samesite test fails, most likely somewhere around here:
https://searchfox.org/mozilla-central/rev/b243debf6235b050b42fd2eb615fdc729636ca6b/netwerk/base/nsNetUtil.cpp#2062

I agree that we should add some carve out so same-site cookies are set in that case.

Comment 7

[Junior [inactive]]

Right, for the failure case we recognize it's foreign here
https://searchfox.org/mozilla-central/rev/ac43d7e69a435ede789827f20ab309da6f04c09b/netwerk/base/nsNetUtil.cpp#2093

which is due to no domain in the triggeringPrincipal
https://searchfox.org/mozilla-central/rev/ac43d7e69a435ede789827f20ab309da6f04c09b/dom/base/ThirdPartyUtil.cpp#326

However, the issue happens only on the Top Sites links.
Like URL bar/bookmark works well.

The principal is from session restore. I'm not sure if it's expected here.
https://searchfox.org/mozilla-central/source/browser/components/sessionstore/ContentRestore.jsm#233-253
I'd like to change component to start moving forward.

Comment 8

[Alphan Chen [:alchen]]

(In reply to Junior [:junior] from comment #7)

Right, for the failure case we recognize it's foreign here
https://searchfox.org/mozilla-central/rev/ac43d7e69a435ede789827f20ab309da6f04c09b/netwerk/base/nsNetUtil.cpp#2093

which is due to no domain in the triggeringPrincipal
https://searchfox.org/mozilla-central/rev/ac43d7e69a435ede789827f20ab309da6f04c09b/dom/base/ThirdPartyUtil.cpp#326

However, the issue happens only on the Top Sites links.
Like URL bar/bookmark works well.

The principal is from session restore. I'm not sure if it's expected here.
https://searchfox.org/mozilla-central/source/browser/components/sessionstore/ContentRestore.jsm#233-253
I'd like to change component to start moving forward.

If it is related to "tirggeringPrincipal", please also see bug 1594162.

Comment 9

[:Gijs (he/him)]

(In reply to Junior [:junior] from comment #7)

The principal is from session restore. I'm not sure if it's expected here.
https://searchfox.org/mozilla-central/source/browser/components/sessionstore/ContentRestore.jsm#233-253
I'd like to change component to start moving forward.

I don't think this is true, I think the principal gets deserialized in session restore, perhaps, but the load should be happening as a result of

https://searchfox.org/mozilla-central/rev/8f7b017a31326515cb467e69eef1f6c965b4f00e/browser/components/newtab/lib/PlacesFeed.jsm#280,284

which explicitly passes a null principal. The URL bar and bookmarks will be passing system principal.

Comment 10

[Jessilyn Davis]

Scott - can you take a look and see what this entails? Thanks!

Comment 11

[:Gijs (he/him)]

Scott asked what the right way to do this would be. This is what the URL bar does: https://searchfox.org/mozilla-central/rev/4537228c0a18bc0ebba2eb7f5cbebb6ea9ab211c/browser/components/urlbar/UrlbarInput.jsm#1528 .

Note that this assumes that the links we've got here cannot be malicious. I'm assuming that we know this to be true for things on the new tab page. If there's a risk that web content or MITM actors can insert malicious things here, we should do some more checks (e.g. checking if the URL's protocol is http/https/file or something like that). It looks like the null principal got added by bug 1435419, but I don't know why they chose a null principal and/or what the reason for that change was, and I can't tell from the bug. Perhaps :Mardak or :k88hudson can help with that.

Comment 12

[Scott [:thecount] Downe]

Attachment: Bug 1599368 - SameSite strict cookies sent from newtab

Comment 13

[Ed Lee :Mardak]

Oh, just realized bug 1433707 is a regular bug now. It's where the Null principal got added.

Comment 14

[Scott [:thecount] Downe]

Dunno how soon I can get back to this, as it seems more involved now and it's not obvious to me what needs to happen, so I'll need to find time to sit down with this and understand what's being requested.

Comment 15

[Christoph Zwerschke]

I can confirm this problem (missing cookie) with 68ESR, 73, 75 and 76. But in 77, 78 and 80 (Nightly) it seems to work (cookie is sent).

Comment 16

[:Gijs (he/him)]

(In reply to Christoph Zwerschke from comment #15)

I can confirm this problem (missing cookie) with 68ESR, 73, 75 and 76. But in 77, 78 and 80 (Nightly) it seems to work (cookie is sent).

I cannot reproduce; the cookie is still missing in 78. How are you testing? Here's my test code (php, hosted locally):

<?php
$gotit = "nope";

if (array_key_exists("foopydoo", $_COOKIE)) {
  $gotit = $_COOKIE["foopydoo"];
}

setcookie("foopydoo", "myvalue", [
  'expires' => time() + 86400,
  'path' => '/',
  'samesite' => 'Strict',
]);

echo "Hello " . htmlspecialchars($gotit);
?>

This prints Hello nope when clicking a bookmark to it on the new tab page (despite opening the page previously and thus setting the cookie), on current nightly and on 78.

I do see a difference in https://samesite-sandbox.glitch.me/ , where I suspect the change in behaviour is caused by bug 1627653 -- but the ticks/crosses there are evaluated based on subframe behaviour, not based on whether the parent frame got cookies.

In other words, I do not believe this is fixed yet.

Comment 17

[Christoph Zwerschke]

(In reply to :Gijs (he/him) from comment #16)

I cannot reproduce; the cookie is still missing in 78. How are you testing?

Thanks for the quick reply.

My app was using the document.cookie value in JavaScript - that seems to work now since version 77, but did not work before. However, you're right - the request cookie header is still not sent. It does not matter for my app, but might be needed by others. I have verified this with the following Flask/Python application. You can easily adapt your PHP code to output the document.cookie value as well.

#!/usr/bin/python3.8

from flask import Flask, request, make_response
app = Flask(__name__)

@app.route('/')
def start():
    result = f"""
    <p>foo = {request.cookies.get('foo')}</p>
    <p>Cookies: <script>document.write(document.cookie)</script></p>
    """
    response = make_response(result)
    response.set_cookie('foo', 'bar', samesite='Strict', max_age=43200)
    return response

app.run(host='127.0.0.1', port='8080')

Comment 18

[Ben]

I confirm that the problem still exists in Firefox 80.0.1.

There is another thing going on that is not discussed here. Our application tries up to 2 redirect requests (303 See Other) to set the cookie. Firefox does process these two requests (I can see that in the server log), but these requests show up in the developer tools very briefly and disappear, even with persist log turned on. And the point is that Firefox ignores the Set-Cookie HTTP headers in these redirect requests. It appears that these first requests are executed in a separate environment.

Comment 19

[:Gijs (he/him)]

(In reply to Ben from comment #18)

There is another thing going on that is not discussed here. Our application tries up to 2 redirect requests (303 See Other) to set the cookie. Firefox does process these two requests (I can see that in the server log), but these requests show up in the developer tools very briefly and disappear, even with persist log turned on. And the point is that Firefox ignores the Set-Cookie HTTP headers in these redirect requests. It appears that these first requests are executed in a separate environment.

It's not really clear whether this issue is related. Does "working around" the samesite=strict issue with the redirects work when users click a link from a different (non-same-origin) website? I'm not intimately familiar with the samesite cookie spec, but I wouldn't really expect it to - the navigation was initiated somewhere else, and the redirects don't affect that, so I'd expect any samesite=strict cookies to still be missing at the end of the redirect chain. If you think that's a bug (or if the behaviour you're seeing is specific to the case of navigating from Firefox's new tab page), please can you file a separate bug? Thank you!

Comment 20

[:Gijs (he/him)]

Scott / Ed, how can we make progress here? It's pretty bad that tiles on the new tab page break websites because their cookies get omitted.

Comment 21

[Jessilyn Davis]

Clearing priority so that this gets re-triaged during triage today.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6e92ff608742
SameSite strict cookies sent from newtab r=Gijs

Comment 23

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/6e92ff608742

Comment 24

[Ben]

(In reply to :Gijs (he/him) from comment #19)

(In reply to Ben from comment #18)
It's not really clear whether this issue is related.
It only happens with the top sites, with and without samesite=strict. So, perhaps not really related, no.

Comment 25

[:Gijs (he/him)]

(In reply to Ben from comment #24)

(In reply to :Gijs (he/him) from comment #19)

(In reply to Ben from comment #18)
It's not really clear whether this issue is related.
It only happens with the top sites, with and without samesite=strict. So, perhaps not really related, no.

OK. If you're able to share specifics in a separate (new bugreport) on here I would still be interested. :-)

Comment 26

[Scott [:thecount] Downe]

Seems the page to test this initially in the bug is down. I was able to get something similar that seems to work here:

1. Open a new profile
2. Navigate to https://samesitetest.com/cookies/set
3. Set a topesite to https://samesitetest.com/cookies/read?test=GET
4. Open the new topsite

expected: should take you to a page with "StrictCookie" :heavy_check_mark: and not "StrictCookie" :x:

Comment 27

[Robert Martin [:romartin], Ecosystem QA]

I have verified that the "Strict Cookies" are applied after navigating from a topsite by following the steps provided in comment 26 using Firefox Beta 83.0b5 (Build ID: 20201027175448) on Windows 10 x64, macOS 10.15.16, and Ubuntu Linux 20.04 x64.