1909609 - (CVE-2025-8364) blob: URI Spoofing Vulnerability Address Bar Display Issue

Status: RESOLVED FIXED

(Firefox for Android :: Toolbar, defect, P3)

Description

[Rifa'i Rejal Maynando]

Attachment: mozilla.mp4

Affected Version mozilla mobile browser : 128.0.1

Summary :

The issue involves URL spoofing vulnerabilities related to how browsers display URLs, particularly in the context of blob URLs and registrable domains. The problem is observed in Mozilla's handling of URLs when the address bar is narrow, and it concerns how the browser prioritizes displaying the registrable domain versus the URL prefix.

Scenario :

When a victim clicks a button that the attacker has exploited, and the attacker creates a subdomain like https://login.google.com.attacker-domain.com, the browser may show a blob URL prefix (e.g., blob:https://login.your-bank.com). This could create an opportunity for spoofing, making users believe that the content is served from a trusted domain (your-bank.com), when in reality it is served from a malicious domain.

Spoofing Potential:

The current URL display behavior of showing the registrable domain helps prevent spoofing by making it clear which domain is actually providing the content. If Mozilla displayed the full URL prefix instead, attackers could exploit this to create convincing phishing or fraudulent pages that appear to be from legitimate sources.

Reference Show URLs Standards :

https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_display_guidelines/url_display_guidelines.md#Eliding-URLs

Reproduce :

1. Upload my exploit file on your domain
2. Open the url
3. Click the button
4. Direct and spoofing

For details on how to reproduce this, please refer to the proof of concept video.

Comment 1

[Rifa'i Rejal Maynando]

Attachment: chrome.mp4

This is a proof of how the Chrome mobile browser handles blob URLs in the address bar.

Comment 2

[Rifa'i Rejal Maynando]

Attachment: exploit.html

This file is used for the exploit.

Comment 4

[Rifa'i Rejal Maynando]

Hallo sir, can i request this to unpublic? or you can hide for exploit.html?

Comment 5

[Roger Yang [:royang]]

Rifa'i, unfortunately I couldn't hide the attachment. I've set it to obsolete so it won't show on the page. thanks

Comment 6

[Daniel Veditz [:dveditz]]

It's possible fixing the basic issue for bug 1670725 will forget to also fix this for "blob:" URLs where the "display origin" is not syntactically an origin internally. Better to make this depend on the other because I bet it will require special handling.

Comment 7

[Andrew McCreight [:mccr8]]

I found this old Chromium issue which looks the same. Indeed, for their case they had to add special handling for blob URLs.

Comment 8

[Rifa'i Rejal Maynando]

Attachment: eligible proof.png

If this is not a duplicate, I think making this report private would be a good idea because it can lead to a potential spoofing attack, as mentioned in reply comment #7. When I checked the eligible bounty page, it seems possible to get a reward. So why was my report flagged with sec-bounty-? Can you explain it? Also, is my report still eligible to receive CVEs?

Comment 9

[Rifa'i Rejal Maynando]

Can you make this report private? I have a new proof of concept method that can potentially lead to spoofing, similar to the issue on issues.chromium.org/issues/40052250

Comment 10

[Chris Peterson [:cpeterson]]

Setting this bug back to a private mobile security bug.

Comment 11

[Rifa'i Rejal Maynando]

Attachment: proof & exploit.zip

So, now that it's private, I am ready to show a new proof of concept.

Requirements to Reproduce:

1. Create a nested domain resembling a familiar website. Example: auth.mozilla.org.[attacker].com
2. Exploit file [exploit.html] and a file for redirecting to the exploit file [redirect.html]

Steps to Reproduce:

1. Create a subdomain that appears familiar when viewed in the address bar. Example: the attacker creates a subdomain like auth.mozilla.org.[attacker].com.
2. Then, upload the exploit file [exploit.html] on main website [attacker.com] and create a file [redirect.html] which contains a button that redirects to auth.mozilla.org.[attacker].com/exploit.html.
3. When the victim visits [attacker.com]/redirect.html and clicks the button, it will appear unsuspicious to the victim.
4. The user inputs their credentials, and then the attacker gains access.

Regards,
Rifa'i Rejal Maynando

Comment 12

[Rifa'i Rejal Maynando]

Sorry, that is an incorrect step. The correct one is...

Steps to Reproduce:

1. Create a subdomain that appears familiar when viewed in the address bar. Example: the attacker creates a subdomain like auth.mozilla.org.[attacker].com.
2. Then, upload the exploit file [exploit.html] on the subdomain website auth.mozilla.org.[attacker.com] and upload a file [redirect.html] on the main website which contains a button that redirects to auth.mozilla.org.[attacker].com/exploit.html.
3. When the victim visits [attacker.com]/redirect.html and clicks the button, it will appear unsuspicious to the victim.
4. The user inputs their credentials, and then the attacker gains access to the victim's account.

Comment 13

[Daniel Veditz [:dveditz]]

I should have restored the sec-bounty request ('?') when we un-duped it. It still might be a dupe, but it's hard to tell since the other bug has not been fixed.

Comment 14

[Rifa'i Rejal Maynando]

Any update about my report?

Comment 15

[Tom Ritter [:tjr] (OOTO until April)]

This is a mass bug change for bug bounty purposes. GUID for this change to search/archive on: c29ab022-4839-4706-86ca-770ef07c519c

Comment 16

[Tom Ritter [:tjr] (OOTO until April)]

This is a mass bug change for bug bounty purposes. GUID for this change to
search/archive on: c29ab022-4839-4706-86ca-770ef07c519c

Comment 17

[Petru-Mugurel Lingurar [:petru]]

Attachment: Showing attacker domain.png

Seems like the work from bug 1812898 fixed this and bug 1670725 also.
Closing as FIXED.
Feel free to reopen if you disagree.

Comment 18

[Daniel Veditz [:dveditz]]

Seems like the work from bug 1812898 fixed this

Apparently untrue, because we ended up fixing it in bug 1969937