Focus iOS Full UXSS Using Server-Side Redirect to Javascript: URI
Categories
(Focus :: Security: iOS, defect)
Tracking
(fxios151.3, firefox151+ fixed, firefox152+ fixed)
People
(Reporter: renwax23, Assigned: issammani, NeedInfo)
References
()
Details
(4 keywords, Whiteboard: [client-bounty-form])
Attachments
(6 files)
This bug is a little complex from my POC and testings but the idea is simple, we have any website that has an <a> pointing to a website which server-side redirects to a javascript: URI the JS code will run on context of the website.
For example:
- Attacker posts a link in Facebook, GitHub profile, YouTube comment or Google search results.
(https://attacker.com/poc.php) - Victim Taps on the link
poc.phpserver-side redirects tojavascript:document.write(origin)- The JS code will run on context of the link which posted on: Facebook, Google...
My POC Code:
<?php
if (isset($_GET['redirect'])) {
$redirect_count = isset($_GET['count']) ? (int)$_GET['count'] : 0;
$final_destination = "javascript:document.write('UXSS POC, Origin: '%2borigin);";
if ($redirect_count < rand(9, 15)) {
$redirect_count++;
header("Location: ?redirect=1&count=" . $redirect_count);
exit();
} else {
header("Location: " . $final_destination);
exit();
}
}
?>
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body style="margin:0; display:flex; align-items:center; justify-content:center; height:100vh;">
<center>
<a href="javascript:start();" style="font-size:40px;">Tap here if not automatically redirected</a>
<script>
function start() {
open('https://www.youtube.com/redirect?q=https://rx23.io/poc/firefox/1.php?redirect=1', '_self');
}
start();
</script>
</body>
</html>
Online POC:
- Open in Firefox Focus iOS https://rx23.io/poc/firefox/1.php
- Tap on
Go to Site - UXSS on
youtube.com
Couple explanations on my POC which is not same as what I initially said about the bug:
- Before redirecting to the
javascript:URI we will redirect the page to itself couple of times (otherwise many taps would be needed to get the UXSS) - I noticed using a random number of redirects will make the POC better otherwise it will need multiple taps
- Instead of just a normal redirect to the YouTube site we are using
window.open()with the_selfwindow reference, this is crucial part of the POC without this it won't work - I also noticed if the PHP file is hosted on a same-site (not same-origin) domain we don't need to use the
open() & _selfjust a normal link to it will work - If you didn't get it with one tap on the link then try again, with this POC my maximum retries was 3 so it should work.
- In case of auto redirects like a client-side open redirect on the targeted site the POC is 0-user interaction we will get UXSS just by opening the POC with no more taps
This bug can also be replicated by visiting a website like (youtube.com) then going to the redirect website (rx23.io/poc/firefox/1.php?redirect=1) by typing the URL inside the address bar and pressing enter the UXSS will trigger on the first origin. but this method is much slower and might require multiple retries to exploit.
Updated•1 year ago
|
Hey team any update here, this is critical bug similar to 1588928
Comment 3•1 year ago
|
||
bug 1588928 is in Firefox for iOS. We thought we fixed the focus equivalent in bug 1860075. There was also a window.open() version in bug 1855030
Did it regress? Is this exploiting a different issue than a raw redirect (given the unreliability, prossibly timing issue?)
(In reply to Daniel Veditz [:dveditz] from comment #3)
bug 1588928 is in Firefox for iOS.
Related (Firefox) fix PR for reference: https://github.com/mozilla-mobile/firefox-ios/pull/5618
Updated•1 year ago
|
Comment 5•1 year ago
|
||
I cannot reproduce this on Firefox Focus 140.0 on an iOS 18.5 device. I've tried both the online URL from comment 0 and the technique from comment 1. I tried many times both ways. Are you using the right version? I can't imagine you're using something as old as a version that didn't have the fix from bug 1860075 (early 2024).
Any hints or ideas on how we can get the results from your movie?
I'm using (Firefox Focus 140.0 (56825) iOS 19.0
This bug looks like some race condition happening which a check is in place sometimes or not, that's why poc is not reliable %100 from my end it works 3/5 times. Tomorrow will try to improve it more and increase the success rate higher. here is another movie just tested it:
https://drive.google.com/file/d/1aAgZTiZhtQkuqlJGgeULzy2W-4sqJ_4f/view?usp=sharing
Another test case: http://rx23.io/test/dice.php?url=https://pwr.wtf/m.html
rx23.io will just open the seconds domain in _self
pwr.wtf is a normal website which has a link to the 1.php?redirect=1 file
You can also use ?url=(any other website) which has a link to the php file, sharing this on a social media or make google crawl the php will also get us xss on them
Here is 9/10 success rate poc (will try to improve it more), on my end it takes 1-10 seconds by using an iframe similar to bug 1719026
| Reporter | ||
Comment 10•1 year ago
|
||
UXSS on google.com -> https://rx23.io/poc/firefox/gxss.html
And here is a video POC for freshly installing Focus on a new device and visiting the link will result in the UXSS -> https://drive.google.com/file/d/1iBfCd4iLVtfvhyuifgNn4NJI3fp1_z6-/view?usp=sharing
Comment 11•1 year ago
|
||
(In reply to Renwa from comment #8)
Here is 9/10 success rate poc (will try to improve it more), on my end it takes 1-10 seconds by using an iframe similar to bug 1719026
I also can't replicate so far. I referenced the attached video but I'm not able to see an issue or reproduce the bug. I've tried locally on my personal device as well as the sim.
@renwa I attached what I'm seeing on all devices I test, after tapping the 'Tap here' the page is stuck on an indefinite loop, but despite waiting I never seem to see any other effect. You mentioned a race condition, is this the result when the race condition fails to expose the vulnerability?
Comment 12•1 year ago
|
||
| Reporter | ||
Comment 13•1 year ago
|
||
Hey @mreagan
I just tested out my POC again it worked flawlessly. Maybe tap the trash icon to clear the browser and try again or close then reopen the browser.
Iframe -> https://rx23.io/test/dice.php?url=https://pwr.wtf/poc.html
YouTube -> https://rx23.io/poc/firefox/1.php
Google -> https://rx23.io/poc/firefox/gxss.html
I find it surprising that you can't reproduce the bug that's why in comment #10 I tried on a freshly installed device, it's probably because of the Race condition happening and once it hits it it's much easier and more success rate in next tries. Here is a video POC just trying all my POCs and all working in first or seconds try: https://drive.google.com/file/d/1fYwZ1WZlBOwFyLMTFib0JxTyab_XQRWC/view?usp=sharing
My device is iPhone 16 running on iOS 26.0 , the device on comment #10 is iPhone 12.
Comment 14•1 year ago
|
||
Hi @renwa,
I'm still having difficulty repro'ing. I tried deleting and re-installing Focus from the app store and am seeing the same results (for example the https://rx23.io/poc/firefox/gxss.html does not show the "UXSS POC" text that is eventually visible in the attached video). I do see the redirecting text, but it's not clear to me why my results are different from the attached video.
I don't think the device type should matter, and it seems unlikely that the iOS version would impact the reproducibility. I noticed your earlier comment mentioned you were on iOS 19 and your most recent comment is on iOS 26 which is in Beta. Just to confirm: are you testing exclusively on iOS 26 currently?
Was the bug more difficult to replicate prior to switching to the iOS 26 Beta?
| Reporter | ||
Comment 15•1 year ago
|
||
Hey @mreagan,
It's really weird that you can't reproduce the bug I just tested again and again and it worked like 8/10 of times, my main device which I do all the tests is iOS 26 on iPhone 16 and from the beginning I tested on that device. After you said it's not reproducible on my end in comment #10 I tried on another device which was iOS 18.5 on iPhone 12 and it worked flawlessly. The mention of iOS 19 in comment #6 is just the string I copied from Focus about page, it seems Focus calls iOS 26 as iOS 19.
This should work on all iOS/iPadOS devices on any version, let me collect some devices and test everything from beginning. This is clearly some race condition or redirect timing flaw that can be improved for 9.9/10 but for now it's shocking I can reproduce this multiple times and you haven't once, there isn't any logical reason that I can think of, geolocation, timezone, internet speed, DNS queries, server cachings...
| Reporter | ||
Comment 16•1 year ago
|
||
Some results after getting multiple devices:
iPhone 16 iOS 26 -> UXSS
iPhone 12 iOS 18.5 -> UXSS
iPad Pro iPadOS 17.7.8 -> No
iPhone 12 iOS 18.3 -> No
| Reporter | ||
Comment 17•1 year ago
|
||
@mreagan Finally figured out what's the root cause of getting the UXSS, that iOS 18.3 which didn't work I just updated it to the latest stable iOS version 18.6 and the UXSS worked without any issues. From my understanding Apple has changed something in iOS 18.5 that introduced this bug and made Focus vulnerable.
Update your iOS to latest version and now check list of POCs I provided in comment #13 .
Also worth noting that you can still sense this vulnerability by trying the POC on same-origin, for example r.com has a same-origin <a> link to r.com/redirect.php which redirects to javascript: URI, when we click on the link the javascript code will execute. After the update we can do this cross-origin.
Comment 18•1 year ago
|
||
I also can't reproduce this using any of the test URLs either; I'm using an iPhone SE on iOS 18.6.
The OS version could be relevant because Apple fixes bugs in the WebView we depend on (and sometimes creates them). They might not be announced security bugs if Apple considered them innocent "behavior changes", but hypothetically we might make assumptions about some such behavior and then end up with an inadvertent security bug if the change invalidates our assumptions.
Maybe this was a regression introduced by Apple in 18.5 and fixed in 18.6?
I assume you tested your testcases on the iOS 18.5 device in "Firefox for iOS" and Safari and could not reproduce in either? If it reproduced in those other browsers that's much stronger evidence it's an Apple bug, but unfortunately not reproducing in those other browsers doesn't completely eliminate the possibility it's an iOS bug.
- If you can't reproduce in 18.6 then we should chalk this up to an Apple bug
- if you CAN still reproduce in 18.6 then we're still stuck with the mystery about what's different between your devices and ours.
Comment 19•1 year ago
|
||
Most of the announced iOS 18.6 bugfixes seem completely unrelated (a lot of memory corruption bugs). There's one that is "Processing maliciously crafted web content may disclose sensitive user information" which could describe a ton of different kinds of things, and seems like a stretch as a description of an UXSS so that's very unlikely. https://support.apple.com/en-us/124147#:~:text=Ahire-,WebKit,Moav
Oh, but 18.6 has only been out a couple of days. When I couldn't reproduce in comment 5 my test device was iOS 18.5 -- the same version as your iPhone 12 where you can reproduce the problem.
Mystery remains.
| Reporter | ||
Comment 20•1 year ago
|
||
In comment #17 I state that after updating my iOS to 18.6 it worked previously on 18.3 it was just loading page.
Now I have 3 devices it works on all of them.
iPhone 12 18.5
iPhone 12 18.6
iPhone 16 26
I am owner of CVE-2025-30466 which is a UXSS in Safari that patched in 18.5 and this bug is also similar to it, not sure if anything is related or changes Apple made that might be this cause.
This will be very interesting and mysterious if patching a UXSS in Safari caused UXSS in another browser.
The main formula in this chain is we need to open the website we want to XSS using open() with _self reference without that it doesn't work.
Also like previously I stated in the not-working devices I was still able to get XSS in same-origin contexts maybe you can try that and which itself it's also a vulnerability: https://rx23.io/poc/firefox/same.html
Comment 21•1 year ago
|
||
@renwa I ran more tests on 18.6 and was able to replicate, though not 100% consistently. But I am seeing the same results now as your attached video on several of the POCs. Will take a closer look at this and update once I have more information on a potential fix etc.
Thanks for your patience and for providing the extensive testing information / links.
| Reporter | ||
Comment 22•1 year ago
|
||
Yay finally, if we have an iframe in the site then it should work 9.9/10 because we can constantly redirect top window to the the javascript: redirect.
In other cases it's random but more than 50%, using the random redirect to itself multiple times then to the javascript: improves the success rate by a lot.
Now you have replicated it I can work on modifying the script to a higher rate.
| Reporter | ||
Comment 23•1 year ago
|
||
When we are on google.com and it's loading our redirect page if we swipe up the Focus app using iPhone home gesture indicator for a little bit or show recent opened apps which Focus becomes out of focus the success rate is 10/10, this might be helpful on your debugging.
I was also able to boost up the success rate by abusing this behavior which we open tel:111 protocol and immediately redirect to the UXSS page, this will make the background tab out of focus just like swiping up normally, I also added some delay 0.15 seconds to the 1.php redirector file.
Comment 24•1 year ago
|
||
Just wanted to note that I still have been unable to replicate this on a physical device, or any device/sim on any iOS besides 18.6. I've reached out to the iOS team to see if anyone can help replicate further.
Comment 25•1 year ago
|
||
Since timing seems to be a component of this, can you tell us about your internet connections?
- wifi? cellular?
- do you know what the speed is?
- what is the latency to the various target sites? Or does that not matter on the devices that reproduce easily? That is, whether you're connecting via wifi to a home server or over a slow cell connection to a server on the other side of the world doesn't affect the reproducability.
I am owner of CVE-2025-30466 which is a UXSS in Safari that patched in 18.5 and this bug is also similar to it, not sure if anything is related or changes Apple made that might be this cause.
This will be very interesting and mysterious if patching a UXSS in Safari caused UXSS in another browser.
That would be ironic but totally plausible if it were credited as a WebKit fix. Since Apple does make the distinction between Safari and WebKit in their advisories it seems less likely a Safari-attributed fix would affect other browsers, but maybe the fix was not fully restricted to the "Safari.app" executable but was in a different shared OS service that Apple doesn't consider to be part of WebKit. Or maybe it even did make a small behavior change in WebKit that Apple doesn't consider a vulnerability on its own.
Looks like that was patched in 18.4 rather than 18.5? https://support.apple.com/en-us/122371#:~:text=CVE-2025-30466 Not that it makes a difference: either way your 18.5 device that has the Focus bug contains the Safari patch.
| Reporter | ||
Comment 26•1 year ago
|
||
- Wifi
- I have 2 different connections 50Mbps and 100Mbps, both same outcome
- "what is the latency to the various target sites" -> It doesn't matter it's reproducible the same on my domain, google, reddit... without any noticeable change
Maybe some code changes happened in both Webkit and Safari but the advisory only mentioned Safari as it's not a particular Webkit bug.
Sorry made a mistake there, yes it was patched in 18.4, on my 18.3 this wasn't reproducible then updated to 18.6 it worked, also the other device on 18.5 is also working, that's why I'm suspecting that after my Safari CVE this thing might be introduced.
Comment 27•1 year ago
|
||
I have 2 different connections 50Mbps and 100Mbps, both same outcome
both very fast! Since Matt can reproduce on the simulator (runs slow) I was wondering if a slow connection was involved. Of course slow networks and slow processing usually lead to different timing/race issues, but since device speed didn't seem to matter (it reproduces on your fast iPhone 16 and the slower simulator, but doesn't reproduce on my slower iPhone SE) it was worth ruling out the possibility of requiring a slower connection to reproduce.
"what is the latency to the various target sites" -> It doesn't matter it's reproducible the same on my domain, google, reddit...
You're right -- I forgot you repro'd it on your own site, too. It wasn't even a very likely cause, but I'm running out of ideas on what difference might be making it so hard for us to reproduce. On the one hand, the fact that Matt can now reproduce in the simulator gives us a chance to figure it out, but we don't know any more about the impact. Are Matt and I are the oddballs and most users are at risk? Or is your situation/configuration the rare one and this timing attack less of a worry.
| Reporter | ||
Comment 28•1 year ago
|
||
Attached video is a new test on iPhone 14 iOS 18.5
I do believe this is critical and every Focus user is at risk because out of 5 devices I tested 4 of them are vulnerable (that one was iPadOS 17.7.8 ).
| Reporter | ||
Comment 29•1 year ago
|
||
Comment 30•1 year ago
|
||
I have been testing repeatedly this morning and still cannot replicate. I've definitely seen this previously a few times on the 18.6 simulator, and I asked a few other folks on the iOS team to try the POC on their devices. One person was able to reproduce on 18.5 and the other was not able to replicate.
I agree there is definitely a timing issue or race condition involved; for some reason it is very difficult for me to reproduce locally.
Comment 31•1 year ago
|
||
I'm reluctantly calling this "moderate" because of our general inability to reproduce except rarely. It's troubling that we are getting such different results from Renwa because there doesn't seem to be a systematic difference that would account for the wildly different success rates.
| Reporter | ||
Comment 32•1 year ago
|
||
Moderate is very unfair for this bug because you don't need to even visit a website to get XSSed, like the Reddit example I showed you with just a link tapping on it we have a uxss. Also the case for iframes which any iframe can redirect the top frame to the javascript: redirect and xss it that doesn't even need any user interaction.
On my iPhone 16 iOS 26.0 the success rate is like 7/10 for a normal redirect or a link such as google.com example for the iframe one which we could redirect multiple times is much higher.
Maybe could you try on a higher cpu performance or iOS version, looks like the race is more winning on a more faster process.
Iframe -> https://rx23.io/test/dice.php?url=https://pwr.wtf/poc.html
YouTube -> https://rx23.io/poc/firefox/1.php
Google -> https://rx23.io/poc/firefox/17.html
Here is a final poc video I just recorded it and showing how easy it is to reproducible and critical severity: https://drive.google.com/file/d/1xhFvyfVeXIBSa3EhsL150AWLmxXRLLTg/view?usp=drivesdk
Before recording I didn't even opened Focus no other visits or tests was done just copy pasting from here and pressed record.
Comment 33•1 year ago
|
||
Additional testing note: I upgraded my personal iPhone 13 to 18.6 and tried replicating the YouTube POC there, so far have not been able to replicate on that device. This is on the same home network where I was able to successfully replicate on the 18.6 simulator, I should add.
| Reporter | ||
Comment 34•1 year ago
|
||
Hey team, I still believe this is a critical issue and 0 or 1 click uxss, after updating your devices could try the pocs again for couple times to see the vulnerability in action. I still don't understand the reason for not being able to reproduce and why works very well on my end, also the new updates are out for everyone and more devices are now vulnerable.
Comment 35•1 year ago
|
||
Quick follow-up: I've spoken with the iOS team and I'm still checking to see if we have an engineer who can investigate a fix. The iOS engineering team is a little pressed for bandwidth at the moment but this issue is definitely on the radar. Will update once I have more information.
| Comment hidden (off-topic) |
Comment 37•1 year ago
|
||
I still don't understand the reason for not being able to reproduce and why works very well on my end
Neither do we and it's very frustrating!
comment 36 about wrong severities in other bugs is off-topic here. Please send your concerns about bug severity ratings to security@mozilla.org
Comment 38•1 year ago
|
||
The severity field is not set for this bug.
:mreagan, could you have a look please?
For more information, please visit BugBot documentation.
| Reporter | ||
Comment 39•10 months ago
|
||
| Reporter | ||
Comment 40•10 months ago
|
||
Sharing a new screen recording from today, this bug still exists and you can try the POCs.
| Reporter | ||
Comment 41•9 months ago
|
||
Hey team, my POC domain is now expired and I created a new set of POCs that should work most of the time and get UXSS on basically every website, here I demonstrate UXSS on Google and YouTube please try them or watch the video to see this is a real unpatched critical vulnerability.
Google: https://qrshaka.fun/poc/ff/1.php?service=google
Youtube: https://qrshaka.fun/poc/ff/1.php?service=youtube
Video POC: https://drive.google.com/file/d/1QHLB0BKmCv-mYIdBqu4ZYwbTN4EAf8wM/view?usp=sharing
POC Code: Attached
Firefox Focus version: Latest v143.0
iPhone 16 on iOS 26.2
| Reporter | ||
Comment 42•9 months ago
|
||
Comment 43•8 months ago
|
||
It would be helpful if you could demonstrate if the site is actually interactive. Looking at your video, it looks like further actions, for example prompting the user to input credentials would not work.
| Reporter | ||
Comment 44•8 months ago
|
||
Is this comment for this bug? What interactive site and input credentials? This is an uxss bug that in the POC I use document.write(origin) and it executes on Google and Youtube domains, no need to input anything we already have full XSS.
Comment 45•8 months ago
|
||
I was able to (intermittently, and with aggressive refreshes) reproduce randomly on both physical iOS 18.7 and 26.2 simulator (say, 3/10). Safari shows an error in the same case, informing that Location: redirecting is only allowed to http(s) schemes. This is bug 1860075 exhibited by following multiple redirects, so the scheme appears not completely sanitized under some circumstances.
Comment 46•8 months ago
|
||
Updated•5 months ago
|
Updated•5 months ago
|
Updated•5 months ago
|
Comment 47•5 months ago
|
||
Verified as fixed on v9000 (72919) with iPhone 16 (iOS 26.5), iPhone 15 Pro Max (iOS 18.7.2), iPhone 17 Pro (26.0), iPhone 16 Pro (26.2), iPhone 17 Pro Max (iOS 26.4.2)
Please note that we've tested using the following: https://firefoxuxss.v12.sh
For v152.0 (72846), we were able to reproduce the issue (see this picture)
For v9000 (72919), you can see the video that it did not reproduce anymore.
Please note that in the video mentioned above, we recorded at the same time v9000 and v152.0, and we performed the same actions; it can be seen clearly that for v152.0 it reproduces.
Also, note that we've tried on 5 devices for ~40 minutes on each device on v9000 (where the fix was implemented), and we could not reproduce the issue anymore with https://firefoxuxss.v12.sh.
Updated•5 months ago
|
Updated•5 months ago
|
Comment 48•5 months ago
|
||
Verified as fixed on Focus iOS 151.3.1 (72936) too, with 17 Pro Max (iOS 26.4.2), klar iPhone 16 Pro (iOS 26.2), iPhone 15 Pro Max (iOS 18.7.2), and iPhone 16 (iOS 26.5).
Updated•5 months ago
|
Updated•4 months ago
|
Updated•2 months ago
|
Description
•