[Site Isolation] Validate the target frame of cross-process postMessage and focus

Under Site Isolation, the UI process relayed postMessage origins it never checked.

Component: WebKit Site Isolation | 1202482

LayoutTests/http/tests/site-isolation/post-message-forged-source-frame.html

+ IPC.addOutgoingMessageListener("UI", (description) => {
+     if (captured || !description || !description.buffer)
+         return;
+     if (description.name !== IPC.messages.WebPageProxy_PostMessageToRemote.name)
+         return;
+     captured = true;
+     // Drop the 16-byte header; IPC.sendMessage writes its own.
+     frame.contentWindow.postMessage({
+         replay: true,
+         name: description.name,
+         bytes: new Uint8Array(description.buffer).slice(16),
+     }, "*");
+ });
...
+ else if (event.data != "probe count 1")
+     finish("FAIL: the iframe reported \"" + event.data + "\", expected \"probe count 1\".");

With Site Isolation, each cross-site frame can live in a different WebContent process, and frames that live elsewhere are represented locally by remote frame proxies. A cross-process window.postMessage or focus goes from the sender's WebContent process to the UI process (WebPageProxy), which looks up the target frame by FrameIdentifier in a global map and forwards the message to the process hosting it. Because the map is global, a frame ID from one page resolves even when the sender has no relationship to it. The receiver builds event.source and event.origin from the source frame ID and origin string the sender supplies, so the UI process has to check those claims instead of relaying them.

This commit adds MESSAGE_CHECKs to WebPageProxy::focusRemoteFrame and postMessageToRemote so the target frame must belong to the page receiving the message, and repeats the target check in WebPage::remotePostMessage. postMessageToRemote also validates the source frame and the claimed origin. If the sender doesn't host the source frame, the message is dropped. If the claimed origin is neither opaque nor the one the UI process derives, the sender is terminated. If the UI process expects an opaque origin, the message is only dropped.

Compromised WebContent (WCP-A)
  │ postMessageToRemote(targetFrameID, sourceFrameID, origin, msg)
  ▼
UI Process: WebPageProxy::postMessageToRemote
  ├─ target frame belongs to this page?  ── no ─► MESSAGE_CHECK (terminate sender)
  ├─ sender hosts source frame?          ── no ─► drop (stale-process race)
  ├─ origin opaque or == UI-derived?     ── no ─► MESSAGE_CHECK (terminate sender)
  │     └─ UI expects opaque (sandbox)?  ── yes, mismatch ─► drop only
  ▼
forward to process hosting target frame
  ▼
WebPage::remotePostMessage ── re-check target frame belongs to page ──► dispatch MessageEvent

Significance

Before this, a compromised WebContent process could forge the target frame, source frame or origin of a cross-process postMessage, or focus a frame in another page. Forging event.source and event.origin is a cross-origin trust boundary break, which makes this a core Site Isolation hardening.

Audit directions

Narrow: audit the sibling cross-process frame messages in WebPageProxy that resolve a FrameIdentifier through a global map without checking that the frame belongs to the sending process or page, such as other *Remote* or frame-targeted IPCs. The match tell is a handler that goes from a sender-supplied frame ID straight to sendToProcessContainingFrame. Wider: origin validation here is deliberately partial. The opaque-origin case only drops the message, because a cross-process parent's sandbox attribute changes do not yet reach the frame's own process, and that leaves a window where UI-process and WebContent-process views of sandbox state diverge. The "drop, don't terminate" path for the stale-process race (LoadDidCommitInAnotherProcess not yet received) is also worth probing for timing issues around frame ownership transfer, such as a frame moving between processes mid-message.