Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 524399615e2486b95285b548abfbacf255f4e776
https://github.com/WebKit/WebKit/commit/524399615e2486b95285b548abfbacf255f4e776
Author: Rupin Mittal <[email protected]>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
Log Message:
-----------
Random page crashes due to invalid IPC message
WebResourceLoader_WillSendRequestReply
https://bugs.webkit.org/show_bug.cgi?id=318878
rdar://181753576
Reviewed by Charlie Wolfe.
Merge back:
WebResourceLoader::WillSendRequest reply may lead to cross-origin cookie
access
https://bugs.webkit.org/show_bug.cgi?id=313866
rdar://180785211
Reviewed by Charlie Wolfe.
Consider this sequence of events:
1. A compromised web process schedules a load with its own origin used for
firstPartyForCookies.
2. NetworkConnectionToWebProcess::scheduleResourceLoad() is called and the
message check passes.
3. The request goes through and the server responds with 302 (redirect).
4. NetworkResourceLoader::continueWillSendRedirectedRequest() calls
WebResourceLoader::WillSendRequest() which gives the web process the
chance
to alter the request that will be sent to perform the redirect.
5. The compromised web process alters the request so that
firstPartyForCookies
is now a different origin.
6. NetworkResourceLoader::continueWillSendRequest() receives this altered
request and passes it off to CFNetwork.
7. The result of this request is that the compromised web process receives
the cookies of this different origin.
There are multiple callsites of continueWillSendRequest(), but only one
place
which allows the web process to alter the request before it's given to
continueWillSendRequest(). So we fix this by adding a message check right
before that callsite that will double check that the origin contained in
this
potentially modified request from the web process is in this web process's
allowed list. If not, the web process will be killed so that it doesn't
recieve
the cross-origin cookies.
We also only do this message check if the web process actually changes the
origin. This is because there are cases where the origin is not yet in the
allowlist but not because the web process modified it (like in:
imported/w3c/web-platform-tests/speculation-rules/prefetch/redirect-url.https.html?origin=cross-site-redirect
where there is a cross-site redirect as part of a prefetch, so the
cross-site
origin is supplied by the server but hasn't made it into the allow list
since
the navigation to it is not complete).
When we a previously attempted to add this message check, we found that it
resulted in users hitting the message check in the wild. Based on the fault
logs,
we speculate that the issue could be:
1. A network load is scheduled with the keep alive option.
2. NetworkResourceLoader::continueWillSendRedirectedRequest() sends the IPC
WebResourceLoader::WillSendRequest().
3. Before the web process can respond, it exits. So the web process does not
call the completion handler.
4. The IPC connection between the network and web process is torn down by
Connection::dispatchDidCloseAndInvalidate().
5. This function first calls
NetworkProcessConnectionToWebProcess::didClose()
which keeps the NetworkResourceLoader alive because of the keepalive
option
and removes the web process from m_allowedFirstPartiesForCookies.
6. Then it calls Connection::invalidate() which calls
cancelAsyncReplyHandlers()
which calls the completionHandler with a default constructed
ResourceRequest.
7. In the completionHandler, the NetworkResourceLoader is alive and the
default
constructed request's firstPartyForCookies is empty (which doesn't match
the
likely non-empty stored firstPartyForCookiesFromRedirectRequest), so we
proceed to the check. Since the web process is no longer in
m_allowedFirstPartiesForCookies, allowsFirstPartyForCookies returns
Disallow
and the message check is hit.
So if the completionHandler is called because of the web process exiting
(and
thus the connection being torn down), we early return before doing the
check.
We also early return in the case where WebResourceLoader::willSendRequest()
responds with a default constucted ResourceRequest if there is no
coreLoader.
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::continueWillSendRedirectedRequest):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/317582@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
