[Webkit-unassigned] [Bug 204498] New: Server side HTTP Cookie in iframe is not accepted

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=204498

            Bug ID: 204498
           Summary: Server side HTTP Cookie in iframe is not accepted
           Product: WebKit
           Version: Safari 13
          Hardware: Macintosh
                OS: macOS 10.15
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Frames
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: eric.lass at webid-solutions.de

Created attachment 384133

  --> https://bugs.webkit.org/attachment.cgi?id=384133&action=review

Simple HTML page with iframe

Hi there.

We've stumbled upon an issue with the Intelligent Tracking Prevention recently and cannot seem to find a solution for it.

One of our customers embeds our web site via an iframe into their own site. We use a simple session cookie on our site. The cookie is created server-side through the HTTP Response Header, which looks like this:

    Set-Cookie: PHPSESSID=sd7f6s76df8s7d6g9sd6g; path=/; secure; HttpOnly

But this cookie does not seem to be accepted at all when the iframe is shown and our page is loaded in it. When we check the Storage tab in the developer console in Safari, there is no cookie shown at all for the domain that is inside the iframe (our own page), only for the main domain (our customers page). One question here is if that view would show the cookie when it was partitioned by ITP or not.

This can be reproduced in a simple isolated test case. One page on domain A has a simple iframe with src on some other page on domain B which (our example page is attached). The server at domain B returns the cookie in the response header as described above. We already tried enabling the ITP debug log, but we do not find any log messages related to ITP (using Console app).

When we turn off ITP and load the iframe, the cookie is created successfully (as expected). If we turn it on again afterwards, the cookie stays and can be used, once we call the "requestStorageAccess" API successfully. But it is obviously not a viable solution to force our users to disable ITP. The user will also not have any reason to directly access our own page outside of an iframe in the case of this customer.

So, the question is: Why is the HTTP cookie that is returned in the response header not accepted/stored in the first place? Is this a bug or are we missing something?

According to the ITP documentation, the HTTP cookie should be accepted when it is marked "Secure" and "HttpOnly", which it is as shown above. Both sites run on HTTPS with valid and accepted certificates, if this makes any difference.

Details on the setup we are using to reproduce the issue:
- Mac mini with macOS Catalina (10.15.1)
- Reproducible with two Safari versions:
  - Safari 13.0.3, WebKit 15608.3.10.1.4
  - Safari Technology Preview, Release 95, 13.1, WebKit 15609.17

Please let me know if you need further details. I'll be happy to provide them.

Regards,
Eric

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191122/45770c13/attachment-0001.htm>