1998702 - Download displayed as text/plain instead of downloaded if there are multiple @ characters in URL "userinfo"

Status: NEW

(Firefox for iOS :: General, defect)

Description

[Achmad Husein Noor Faizi]

Attachment: IMG_4869.MP4

Product: Firefox for iOS (latest version)

Platform: iOS (latest version)

Severity: High — Causes browser crash and data loss risk

Description:
A browser stability issue occurs in Firefox for iOS when handling file downloads involving URLs containing multiple redirect function symbols (@). The mishandling of this character in the redirect chain leads to a crash affecting both the active and originating browser tabs. This results in full tab termination and potential data loss for the user.

Steps to Reproduce:

1. Host the following PoC or use the provided one at https://n13s.site/611/combined.html.
2. Click the Download From Original Site button.
3. Observe that a new tab opens and attempts to download the file.
4. Instead of successfully downloading the file, due to the massive use of redirect function symbols (@) in the URL, the browser tries to directly access the malformed redirect target.
5. Observe that both the new and original tabs crash simultaneously.

Expected Result:
The browser should properly handle redirect URLs containing function symbols and proceed to download the file safely without crashing.

Actual Result:
Both the originating and newly opened tabs crash due to improper handling of @ symbols in redirect URLs.

Impact:

• Browser instability and tab crashes
• Potential user data loss (e.g., form inputs or unsaved data in other tabs)
• Potential denial of service scenario if used maliciously

PoC URL:
https://n13s.site/611/combined.html

Recommendation:
Validate and sanitize redirect URLs containing special characters like @ before attempting direct access or download handling to prevent memory or pointer corruption leading to crashes.

Video PoC:

Comment 1

[Daniel Veditz [:dveditz]]

The download url is: https://google.com@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@download.virtualbox.org/virtualbox/7.0.8/VirtualBox-7.0.8-156879-Win.exe

I don't see the tabs crashing?

Comment 2

[Achmad Husein Noor Faizi]

im trying on iPhone 11 and iPhone 13 this issue is still reproducible, but I thought its not direct crash, the issue is makes the tabs fails to renders the page referrers and also the referred page (the https://n13s.site/611/combined.html) and the download URL (https://google.com@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@download.virtualbox.org/virtualbox/7.0.8/VirtualBox-7.0.8-156879-Win.exe)

Comment 3

[Achmad Husein Noor Faizi]

Attachment: IMG_4906.MP4

newest PoC for newest version

Comment 4

[Daniel Veditz [:dveditz]]

URLs containing multiple redirect function symbols (@)

Those are not "redirect" symbols. That is the delimiter between a URL's "userinfo" and the host. Putting passwords in URLs is a terrible idea and this URL feature has been STRONGLY discouraged since the 90s. Besides, it only "works" with HTTP Auth which is hardly used, so most users have never seen this feature. Browsers generally strip the userinfo for both user privacy (don't show the password on the screen) and as an anti-spoofing measure to make clear what site the user is really on. This results in claims that it's "redirecting" when it's simply misunderstanding URL syntax.

According to standard URL parsing the last "@" is used as the delimiter and others are considered part of the userinfo and encoded as %40. For example, on many sites your ID is your email address with @ in it, and a strong password might use @ as a "special character". With this spoofy URL the 3 browser engines I tested—Gecko (Firefox), WebKit (Safari, all iOS browsers), and chromium (Chrome, Edge, etc)—all parsed this the same way.

4. Instead of successfully downloading the file, due to the massive use of redirect function symbols (@) in the URL, the browser tries to directly access the malformed redirect target.

Multiple @@ signs does appear to be the bug. If I change the userinfo part to "f@" or "f@@" then I get the expected download (there is a content-type: application/octet-stream on the file). But "@f@" or three @-signs in a row makes us ignore the content type and show the raw bytes as text/plain:
@f@ example
f@@@ example

This must be processing done in our front-end code because the back-end webview doesn't have this problem in other iOS browsers. This doesn't seem to be a security problem, though. The site is functionally broken, but there's nothing a malicious site couldn't already do by serving the content as text/plain in the first place. You don't get the file you wanted (maybe?) and displaying huge files will cause problems because of memory and CPU used to display it.

The visual display problems in the multi-tab view are because it's such a giant file either we can't thumbnail it, or maybe it takes so long to download we didn't wait long enough to capture the thumbnail. You could reproduce that by navigating to any giant text/plain document. It's probably a known problem, but in any case that's a separate issue and is just a visual glitch, not a security problem.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mreagan, could you have a look please?

For more information, please visit BugBot documentation.