Storage partitioning and XS-Leaks

Tags: session, cookie, xsleak

Level: advanced

Method

1. Name the browser

   Record the browser and version. Partitioning and third-party cookie behavior are not the same in every engine, and they change.

   Tools: browser

2. See how the cookie is set

   Record the browser, the version, and whether that profile blocks third-party cookies. A credential cookie set from a cross-site frame without Partitioned is still sent in Chrome when third-party cookies are allowed. It is dropped in browsers and modes that block them. The report names which of those you observed.

   Tools: browser

3. First-party leaks still count

   Window length, error timing, and search-oracle tricks on a first-party page are a different question. Confirm the signal still exists in the browser you named.

   Tools: browser

4. COOP, COEP, and framing

   Cross-Origin-Opener-Policy and framing headers change what a popup can observe. Read the headers on the page you are testing before you claim a cross-window leak.

   Tools: Burp Suite

5. Shared cache as a channel

   A cache that stores a response without varying on the viewer can still be a cross-user channel. That overlaps cache deception. Say which one you measured.

   Tools: Burp Suite

6. Impact needs a secret

   A bit of information about a page you already own is a primitive. The report needs a secret the attacker should not learn, demonstrated with accounts you own.

   Tools: browser

Field notes

• Do not file 'third-party cookies are blocked' as a vulnerability.
• CHIPS is the Partitioned attribute. It is not a replacement for HttpOnly or SameSite.
• If the signal only reproduces in an old browser, say so.

References

• https://developer.mozilla.org/en-US/docs/Web/Security
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie