Arbitrary JS execution on ReaderView by abusing wrong HTML replacement order
Categories
(Firefox for iOS :: Reader View, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| fxios | 151.2 | --- |
People
(Reporter: sdna.muneaki.nishimura, Assigned: issammani)
References
()
Details
(Keywords: csectype-priv-escalation, reporter-external, sec-high, Whiteboard: [client-bounty-form])
Attachments
(1 file)
|
2.34 KB,
text/html
|
Details |
Steps to Reproduce:
- Visit https://csrf.jp/2026/fxios-reader-jsonld-xss3.html
- Push ⚡️ button in address bar
- UXSS is fired and an alert dialog is shown in ReaderView domain
Root Cause:
My further investigation revealed that similar but different attack vectors to Bug 2036573 still exist.
The HTML escaping implemented as a countermeasure for Bug 2036573 is effective and that provides enough protection against certain types of UXSS attacks.
However, there was another weakness in the order of HTML replacement in the following code.
https://github.com/mozilla-mobile/firefox-ios/blob/f1bbf0923d836e9789cb9436b8ea73c3c77bd325/BrowserKit/Sources/WebEngine/WKWebview/Scripts/ReaderMode/ReaderModeUtils.swift#L27
In this code, the %READER-CONTENT% placeholder, which contains the HTML of the original page, is substituted into the ReaderView HTML template, followed by the substitution of %READER-JSONLD%.
Therefore, if the original page contains the text %READER-JSONLD%, it will be replaced with the JSON+LD data extracted from the original page's header tag.
The fix for Bug 2036573 escapes malicious HTML tags in the JSON+LD, but it doesn't escape double quotes “ because it must be kept due to JSON syntax.
As a result, if the original page's content contains the text <img src="/test.png?%READER-JSONLD%"> and the page JSON+LD contains
{"onload=alert(document.location);&# x2F;/“: ...}”} }, these will be concatenated in the HTML template, resulting in an XSS payload: <img src="/test.png?{"onload=alert(document.location);//“”>.
This UXSS is triggered on the ReaderView's origin. The potential impact of this UXSS is as described in the comments for the previous Bug. An attacker could steal data from any other site (such as the victim's Bugzilla API key).
Expected Behavior:
Since the original page's HTML can contain other placeholder strings, the %READER-CONTENT% substitution should be performed after all others.
Additionally, in order to prevent such UXSS attacks, a Content Security Policy (CSP) that blocks inline script execution was previously implemented. However, it seems this commit has disabled that CSP.
It would be desirable to re-enable the CSP policy. For example, a similar feature in the Brave browser uses more strict CSP.
Updated•4 months ago
|
Updated•4 months ago
|
Updated•3 months ago
|
Comment 1•3 months ago
|
||
Verified as fixed on v151.2 (72419) RC 2 with iPhone 16 (iOS 26.4.2).
Tried on v151.1 (71989) and I was able to see the UXSS is fired and an alert dialog is shown in ReaderView domain.
On v151.2 (72419) the UXSS is not fire anymore and the dialog alert is not displayed, the website is correctly displayed in reader mode without any issues.
Video
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•14 days ago
|
Description
•