← WebKit — 2026-W39
bc9c8e1b2b040e22120eb400c15def5ac28be6aa Stop sending parent frame identifier over IPC with FrameInfoData
severity low
class Spoofing
confidence 0.3
signal score 6.47
Source/WebKit/Shared
Primitive: stops trusting a renderer-supplied parentFrameID, deriving frame parentage from the UIProcess frame tree
Triage note: Removes the IPC-serialized FrameInfoData::parentFrameID and instead computes the parent via WebFrameProxy::webFrame(frameID)->parentFrame() in the UI process (frame tree assembly, immediate-action hit test, BiDi). Anti-spoofing hardening against a compromised web process reporting false parentage, but largely intertwined with a back/forward-cache child-frame refactor; no concrete exploit in the diff.
Triage note: Removes the IPC-serialized FrameInfoData::parentFrameID and instead computes the parent via WebFrameProxy::webFrame(frameID)->parentFrame() in the UI process (frame tree assembly, immediate-action hit test, BiDi). Anti-spoofing hardening against a compromised web process reporting false parentage, but largely intertwined with a back/forward-cache child-frame refactor; no concrete exploit in the diff.
Structural signals: smartptr_member_added (+6.47)
Commit message
Stop sending parent frame identifier over IPC with FrameInfoData
https://bugs.webkit.org/show_bug.cgi?id=324394
rdar://187625604
Reviewed by Ben Nham.
This continues removing pieces from FrameInfoData and using UI process
state instead, which I began in 321220@main. WKFrameInfo is supposed
to be a snapshot of what the frame was when it was created, so I made
the title follow that pattern too.
Also, I removed a hack to omit the frames from b/f cached frames in
WebFrameProxy::getFrameTree and did it the proper way by moving the
frames to the b/f item in WebPageProxy::didCacheBackForwardItem and
preparing for them to come back in WebPageProxy::didTakeBackForwardItemForRestoration.
An alternative to this could've been to co_return std::nullopt in
WebFrame::getFrameInfo if !isMainFrame() && !parentFrame(), but that
would preserve the hacky UI process having the wrong state.
This is covered by SiteIsolation.QueryFramesStateAfterNavigating
added with the original hack, which I modified to also test with site
isolation turned off.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
* Source/WebKit/Shared/FrameInfoData.cpp:
(WebKit::legacyEmptyFrameInfo):
* Source/WebKit/Shared/FrameInfoData.h:
* Source/WebKit/Shared/FrameInfoData.serialization.in:
* Source/WebKit/UIProcess/API/APIFrameInfo.cpp:
(API::FrameInfo::stateSnapshot):
(API::FrameInfo::FrameInfo):
(API::FrameInfo::parentFrameHandle const):
(API::FrameInfo::title const):
(API::certificateInfoFromFrameID): Deleted.
* Source/WebKit/UIProcess/API/APIFrameInfo.h:
* Source/WebKit/UIProcess/ProvisionalPageProxy.cpp:
(WebKit::ProvisionalPageProxy::cancel):
* Source/WebKit/UIProcess/WebFrameProxy.cpp:
(WebKit::WebFrameProxy::getFrameTree):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didPerformImmediateActionHitTest):
(WebKit::WebPageProxy::didCacheBackForwardItem):
(WebKit::WebPageProxy::didTakeBackForwardItemForRestoration):
* Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::navigationActionData const):
* Source/WebKit/WebProcess/WebPage/WebFrame.cpp:
(WebKit::WebFrame::info const):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::getFrameTreeForBackForwardCacheEntry):
* Source/WebKit/UIProcess/Automation/BidiBrowsingContextAgent.cpp:
(WebKit::BidiBrowsingContextAgent::getNavigableInfo):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::TEST(SiteIsolation, QueryFramesStateAfterNavigating)):
(TestWebKitAPI::TEST(SiteIsolation, QueryFramesStateAfterGoingBackToCachedPageWithIframe)):
Canonical link: https://commits.webkit.org/321918@main
Before / after
Loading diff…
On This Page