Issue 1159586: Split browsing context groups by top-level site

[uazo]

https://bugs.chromium.org/p/chromium/issues/detail?id=1159586

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/common/metrics/post_message_counter.cc;l=1;bpv=1

test with https://wpt.live/html/browsers/windows/post-message/

[uazo]

@PF4Public if you have time, try checking this too.

if I understand correctly, basically today a first party can communicate with itself via postmessage when it is a third party even between different partitions.
a slap in the face to partitioning by default. :)

[PF4Public]

if I understand correctly, basically today a first party can communicate with itself via postmessage when it is a third party even between different partitions.

@uazo Could you please rephrase your statement above? I'm not sure I completely understand you.

From what I read, in order to send a message over window.postMessage(), caller needs to somehow obtain a handle of the target window, where it wants to send the message. This could be only obtained by opening another window or having an iframe in DOM. This indeed could be abused, but it is technically very difficult to exploit on third-party webpages.

[uazo]

Could you please rephrase your statement above? I'm not sure I completely understand you.

you must excuse me, I thought I could do it but I have not yet had time to double check the code, but simply reading it:

PostMessageType GetPostMessageType(
    const blink::StorageKey& source_storage_key,
    const blink::StorageKey& target_storage_key) {
  // We want these storage keys to behave as though storage partitioning is on
  // for convenience.
  const blink::StorageKey source_3psp_key = source_storage_key.CopyWithForceEnabledThirdPartyStoragePartitioning();
  const blink::StorageKey target_3psp_key = target_storage_key.CopyWithForceEnabledThirdPartyStoragePartitioning();
....
  } else if (source_3psp_key.IsFirstPartyContext() &&
             target_3psp_key.IsThirdPartyContext()) {
    // If the source is first party and the target is third party . . .
    if (source_3psp_key.origin() == target_3psp_key.origin()) {
      // . . . we note if their origins are identical . . .
      return PostMessageType::kFirstPartyToThirdPartyDifferentBucketSameOrigin;         <---------
....

kFirstPartyToThirdPartyDifferentBucketSameOrigin means precisely the same site but the sender is first-party and the receiver is third-party, but there are also kThirdPartyToFirstPartyDifferentBucketSameOrigin and kThirdPartyToThirdPartyDifferentBucketSameOrigin

From what I read, in order to send a message over window.postMessage() caller needs to somehow obtain a handle of the target window, where it wants to send the message

a window.top.opener might be sufficient, but tests could indicate exactly how.
I'll have a better look when I get back, thanks for taking the time!

[PF4Public]

kFirstPartyToThirdPartyDifferentBucketSameOrigin means precisely the same site but the sender is first-party and the receiver is third-party, but there are also kThirdPartyToFirstPartyDifferentBucketSameOrigin and kThirdPartyToThirdPartyDifferentBucketSameOrigin

Yes, but how could first party be third-party at the same time?

[uazo]

Yes, but how could first party be third-party at the same time?

In different browsing context, by simplifying, different tabs.

1) top frame site A
    |
     ---- contains iframe site B
          |
          ------ opens a new tab with the B
                  |
2)                 ---- contains iframe site A

(1) and (2) are first party and third-party at the same time

[PF4Public]

This won't go unnoticed by user though!

[uazo]

This won't go unnoticed by user though!

My example is just to make you understand how it is possible, I haven't checked yet.
If it was only as I wrote, the various actors don't need to exchange messages to pass information, they could do it through urls.

[PF4Public]

I wonder if it would be possible to create a simple proof of concept to verify if this woks or not :)

[uazo]

should not be necessary, I think I saw an associated Ukm, tomorrow I will tell you

[uazo]

I saw an associated Ukm

nothing, I just don't understand how you can read that information.
I asked for help https://groups.google.com/a/chromium.org/g/chromium-dev/c/wKSDHEkGVFo

[uazo]

I asked for help

they replied: nothing, I guess it won't be possible to tell if sites exploit that possibility and how.
I think I'll activate that flag regardless, although I don't like doing it without fully understanding why, I'll add optional logs.

[PF4Public]

I don't like doing it without fully understanding why

Creating proof-of-concept could help with that

[uazo]

it's a lot of work... I don't know, I think about it.

[PF4Public]

it's a lot of work

It is, but it should give you 100% confidence on whether it is exploitable and whether your solution fixes this issue.

[uazo]

It is, but it should give you 100% confidence on whether it is exploitable and whether your solution fixes this issue.

But I would reach the same goal if I blocked it and produced a log, exactly as google does.
and once you find the site, check how it does it.

[PF4Public]

Programmers would call this a Probabilistic Solution. You don't know when you catch it and you don't even know if you catch it at all. In addition to that you'll later have no way of telling whether your solution works or not. Probabilistic Solutions are not regarded well by programmers as far as I know.

I'm not telling you that you are wrong, but it can take some (unpredictable) time before you have any results.

PS: I'm not a programmer btw :)

[uazo]

but it can take some (unpredictable) time before you have any results.

Yeah, especially without any log!
I guess something should be done first to warn me uazo/cromite#323