Bug 233128 - Navigation from CodePen iframe to CodePen top frame makes CodePen servers think the user is not logged in
Summary: Navigation from CodePen iframe to CodePen top frame makes CodePen servers thi...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: John Wilander
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-11-15 07:43 PST by John Wilander
Modified: 2022-02-28 21:08 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Wilander 2021-11-15 07:43:24 PST
This tweet https://twitter.com/chriscoyier/status/1459304937230417920?s=21 by Chris Coyier shows in a screencast how clicking to navigate from a cross-site CodePen iframe leads to landing on a CodePen top frame page which shows the user as logged out when they are actually logged in.

Questions to investigate:
1) If the user truly logged out after this navigation or is it just that page load that sees the user as logged out?
2) The iframe obviously will not see the user as logged in since third-party cookies are blocked. Is the iframe changing something in the navigation based on this fact, which in turn makes the landing page believe the user is logged out?
3) Are SameSite cookies at play? We’ve had a couple of bugs historically where SameSite cookie treatment in WebKit differs from Gecko and Chromium for cross-site navigations.
4) Are ServiceWorkers at play? We’ve seen a couple of reports where the combo of SameSite cookies and ServiceWorkers has led to bugs.
Comment 1 Chris Coyier 2021-11-15 16:00:34 PST
Thanks so much for opening this John! Indeed this is a weird bug we've been trying to track down without luck so far. To answer the questions....

1) They are definitely logged out. There is a cookie called `cp_session` that just gets wiped out after the link click. https://d.pr/i/bVoA1A

2) Yeah there is no need to attempt to see if a user is logged in or not with the embed itself.

3) Looks like SameSite = Lax (is this the culprit?)

4) No ServiceWorkers in use.
Comment 2 John Wilander 2021-11-15 16:23:20 PST
(In reply to Chris Coyier from comment #1)
> Thanks so much for opening this John! Indeed this is a weird bug we've been
> trying to track down without luck so far. To answer the questions....
> 
> 1) They are definitely logged out. There is a cookie called `cp_session`
> that just gets wiped out after the link click. https://d.pr/i/bVoA1A

Is the cookie deleted, you say? Is it the server that deletes it or overwrites it with a new one?

What I would assume here is one of these things happening:

a) The navigation from the iframe to the top frame doesn't carry the SameSite=lax cookie and so the resulting page load shows the user as logged out. However, a fresh of that page would show the user as logged in again because now the SameSite=lax cookie is sent.

b) The navigation from the iframe to the top frame doesn't carry the SameSite=lax cookie and the server deletes/overwrites some state in the response based on thinking that the user is not logged in. Even a fresh of the page will show the user as logged out because now their login cookie is indeed gone or overwritten.

> 2) Yeah there is no need to attempt to see if a user is logged in or not
> with the embed itself.
> 
> 3) Looks like SameSite = Lax (is this the culprit?)

It could be. We've had cases where our logic for SameSite (lax or strict) cookies has differed from Gecko and Chromium. Sometimes there is no standardized test so it's a case of a de facto standard. See this one for instance: https://bugs.webkit.org/show_bug.cgi?id=208049

> 4) No ServiceWorkers in use.

Good to know.

Some follow-up questions:

5) To make sure, is the `cp_session` cookie …
 a) … just not sent in the navigation but still there on a reload or fresh load?
 b) … deleted by WebKit during the navigation?
 c) … deleted by the server in the navigational response? Deleted here means set to an expiry in the past.
 d) … overwritten by the server in the navigational response?

6) Are there any cross-site redirects in the navigation or does it go directly to the destination site?

7) Are there any same-site redirects in the navigation does it got directly to the destination page?

8) Can you share the link to reproduce the issue?

Thanks!
Comment 3 Chris Coyier 2021-11-16 07:03:02 PST
> > 1) They are definitely logged out. There is a cookie called `cp_session`
> > that just gets wiped out after the link click. https://d.pr/i/bVoA1A
> 
> Is the cookie deleted, you say? Is it the server that deletes it or
> overwrites it with a new one?
> 
> What I would assume here is one of these things happening:
> 
> a) The navigation from the iframe to the top frame doesn't carry the
> SameSite=lax cookie and so the resulting page load shows the user as logged
> out. However, a fresh of that page would show the user as logged in again
> because now the SameSite=lax cookie is sent.
> 
> b) The navigation from the iframe to the top frame doesn't carry the
> SameSite=lax cookie and the server deletes/overwrites some state in the
> response based on thinking that the user is not logged in. Even a fresh of
> the page will show the user as logged out because now their login cookie is
> indeed gone or overwritten.

It's `b` here. Refreshing the page the user is still logged out. 


Here's the steps to check it out...

1) Be logged in on CodePen. Accounts are free so I hope that's not too much trouble. Be at some page. Any should do, but here's one: https://codepen.io/manz/pen/dyzgWbo

2) Go to a third-party site with an Embedded Pen, like this https://css-tricks.com/almanac/properties/b/background-image/#demo

3) Click the "Edit on CodePen" link in the upper right of the embed.

4) You'll find yourself logged out on CodePen. If you got back to the page you had open in Step 1 and refresh, you'll see you are logged out there too. No amount of refreshing logs you in. 


> 
> Some follow-up questions:
> 
> 5) To make sure, is the `cp_session` cookie …
>  a) … just not sent in the navigation but still there on a reload or fresh
> load?
>  b) … deleted by WebKit during the navigation?
>  c) … deleted by the server in the navigational response? Deleted here means
> set to an expiry in the past.
>  d) … overwritten by the server in the navigational response?

I gotta imagine it's b, because if it was our servers, it would manifest in browsers other than Safari. 


> 6) Are there any cross-site redirects in the navigation or does it go
> directly to the destination site?
> 
> 7) Are there any same-site redirects in the navigation does it got directly
> to the destination page?

To both 6 and 7, no redirects at all, It's just a straight-up anchor link that goes to where it goes. 

> 
> 8) Can you share the link to reproduce the issue?

See steps above.

Anything else I can dig into lemme know.
Comment 4 Radar WebKit Bug Importer 2021-11-22 07:44:21 PST
<rdar://problem/85675333>
Comment 5 John Wilander 2021-12-06 17:28:46 PST
Sorry for the delay.

# Part 1

I have now confirmed that:
1) If I change the cp_session to SameSite=none, I land as logged in.
2) The cp_session cookie is refreshed on every page load which means that it is reset as SameSite=lax as soon as I load a CodePen page after manually changing it to SameSite=none.
3) The navigation that blocks SameSite=lax cookies also blocks new cookies set as SameSite=lax so even though the cross-site navigation lands me as logged in, the next page load from CodePen has me logged out because the server tried to set a new SameSite=lax cp_session cookie and that was blocked.

This points in two directions:

a) It's highly unlikely that WebKit is *deleting* any cookies. I mentioned this before. The test results instead point to CodePen servers setting a new cp_session cookie on every page load which overwrites the old cookie.

b) WebKit is blocking SameSite=lax cookies in the cross-site navigation from css-tricks.com to codepen.io. This may be different behavior from Gecko and Chromium. The result is that the server doesn't get the cp_session cookie on the navigation and sets a new cookie state on the response that represents an unknown or logged out user.

# Part 2

The link on css-tricks.com looks like this:
<a class="edit-on-codepen" target="_blank" rel="noopener" href="https://codepen.io/team/css-tricks/pen/ogqWJL" title="Edit on CodePen">…</a>

If I change the target from _blank to _top, I stay logged in. That's where I will continue this investigation.
Comment 6 John Wilander 2021-12-07 13:46:29 PST
Unable to test right now since CodePen seems to be down. Getting this error message the top of the page:

"This website codepen.io/ is currently offline. Cloudflare's Always Online™ shows a snapshot of this web page from the Internet Archive's Wayback Machine. To check for the live version, click Refresh."

I suspect it's related to the AWS outage today.
Comment 7 Jakob L 2021-12-14 09:37:46 PST
This may be related to https://bugs.webkit.org/show_bug.cgi?id=230350.

When loading your own site through a third-party iframe, WebKit doesn't send SameSite=Lax|Strict cookies, but accepts them.
This broke the login on one of my sites, because the webapp will think there is not login-cookie (eg PHPSESSID) and set a new one, thus overwriting the original login-cookie with a new (empty) one.
Comment 8 John Wilander 2021-12-14 09:39:30 PST
(In reply to Jakob L from comment #7)
> This may be related to https://bugs.webkit.org/show_bug.cgi?id=230350.
> 
> When loading your own site through a third-party iframe, WebKit doesn't send
> SameSite=Lax|Strict cookies, but accepts them.
> This broke the login on one of my sites, because the webapp will think there
> is not login-cookie (eg PHPSESSID) and set a new one, thus overwriting the
> original login-cookie with a new (empty) one.

Thanks for the link. I've related the two issues.