[Webkit-unassigned] [Bug 221180] New: Storage partitioning should be double-keyed for security

[bugzilla-daemon at webkit.org]

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

            Bug ID: 221180
           Summary: Storage partitioning should be double-keyed for
                    security
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: arturjanc at gmail.com

Today, WebKit partitions network state by the site of the top-level document, meaning that only subresource requests to endpoints same-site with the top-level document with include credentials. This is sufficient to achieve the privacy goals of partitioning, but it doesn't provide robust protection against security issues because it permits cross-site frames to send credentialed requests to endpoints within the top-level site, which in turn allows the exploitation of bugs such as CSRF, XSSI, or other XS-leaks.

For example, if any document within a given site contains an iframe which hosts third-party content (e.g. an ad, a translation engine, or any application which sanitizes HTML but allows user-controlled frames), scripts within the iframe will be able to load resources from the first-party site which will still be served from the cache. This gives attackers the ability to exploit various cache-based XS-leaks in the top-level site. Because the key is the top-level site and not the origin, this means that any eTLD+1 with a third-party frame will remain vulnerable to information leaks: an attacker can open a pop-up to the document with the iframe and execute their attack from the frame.

To fix this, consider double/triple-keying the state not just on site of the top-level document, but also on the site (or ideally, origin) of the loading document. AFAIK this matches the approach taken by Chrome:
https://developers.google.com/web/updates/2020/10/http-cache-partitioning#how_will_cache_partitioning_affect_chromes_http_cache

See also a related bug in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1681036

-- 
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/20210130/d7a898b6/attachment.htm>