1863788 - (CVE-2024-26282) Potential UXSS through <link rel=canonical> on Firefox for iOS

Status: VERIFIED FIXED

(Firefox for iOS :: General, defect)

Description

[Muneaki Nishimura]

Attachment: potential_uxss_through_canonical_link.mov

When the current URL starts with /amp, Firefox for iOS recognizes an URL indicated by <liink rel=canonical> as the current page URL.
https://github.com/mozilla-mobile/firefox-ios/blob/e8a99cadf78ecb15db98609a702704480fbc4182/Client/Frontend/UserContent/UserScripts/MainFrame/AtDocumentEnd/MetadataHelper.js#L21

Also, when the page is bookmarked, the URL specified in the <link rel=canonical> is added instead of the current URL.
https://github.com/mozilla-mobile/firefox-ios/blob/7b798d538aedb8e17040c049fcc7715fcfb47e38/Client/Frontend/Browser/BrowserViewController/BrowserViewController%2BKeyCommands.swift#L45

Then, Firefox doesn't validate given canonical URL, so any scheme URL can be added to the bookmark.

Thus, if an attacker specifies a javascript: scheme URL, it's possible to execute JavaScript on any site opened at the time by opening the bookmarked page. These is a potential for UXSS.

Comment 1

[Muneaki Nishimura]

It seems that this bug could be resolved by validating the <link rel=canonical> URL scheme in the following code.
https://github.com/mozilla-mobile/firefox-ios/blob/8821dca58c62cc6c2485f9fce82606f926b0c0cb/Client/Frontend/UserContent/UserScripts/MainFrame/AtDocumentEnd/MetadataHelper.js#L25

An example of the validation code is below.

try {
  const canonicalUrl = new URL(canonicalHref, location);
  if (canonicalUrl.protocol.match(/^https?:$/)) {
    metadata.url = canonicalHref;
  }
} catch(error) {
}

Comment 2

[Daniel Veditz [:dveditz]]

need to re-rate this: the malicious page can't force the victim to create the bookmark nor use the bookmark. The consequences for the user if they do so might be severe, but this issue is more of a "booby-trap" that will only hit a fraction of the people it's aimed at.

Comment 3

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

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

For more information, please visit BugBot documentation.

Comment 4

[lmarceau]

Attachment: GitHub Pull Request

Comment 5

[Daniel Veditz [:dveditz]]

Laurie: will this fix be in v123 ? Please set the version field as appropriate

Comment 6

[Andrei Bodea[:andrei]]

Verified as fixed on v123 (38400) with iPhone 15 Pro (17.1.2).

Please note that I did the following steps:

• Opened Firefox
• Accessed csrf.jp/uxss.php
• Added the csrf.jp/uxss.php as a bookmark.
• Accessed bookmark sections and opened csrf.jp/uxss.php
  The loading bar page was just displayed again (like a refresh) but there was no internal://local uxss prompt displayed anymore.

Muneaki Nishimura if you can please confirm that this is the behavior we want to see I would appreciate it.

Comment 7

[Muneaki Nishimura]

Thanks for your confirmation. When you check your bookmarks and that URL is https://csrf.jp/amp/uxss.php, this is the expected behavior. I have also confirmed that it is fixed in the master branch.

Comment 8

[mreagan]

Attachment: advisory.txt