Open Bug 1780484 Opened 2 years ago Updated 5 months ago

Homepage and NewTab values do not appear to be validated

Categories

(Firefox :: New Tab Page, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: mixedpuppy, Unassigned)

References

Details

(Keywords: sec-want)

While working on updates in webextension code related to homepage and newtab, the question of validating the values we get from Homepage.get and window.BROWSER_NEW_TAB_URL came up. My expectation is that those modules would validate the data. It appears that they will accept and return any value regardless of whether it is a valid url. Rather than every consumer validating those values, I think those modules should.

NewTab: https://searchfox.org/mozilla-central/rev/ffb50da3ca89100b6ae5054cfe69c187679515f0/browser/modules/AboutNewTab.jsm#133-151

HomePage: https://searchfox.org/mozilla-central/rev/ffb50da3ca89100b6ae5054cfe69c187679515f0/browser/modules/HomePage.jsm#189-207

https://searchfox.org/mozilla-central/rev/ffb50da3ca89100b6ae5054cfe69c187679515f0/browser/modules/HomePage.jsm#38-58

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(dharvey)
Severity: -- → S4
Type: defect → enhancement
Flags: needinfo?(dharvey)
Priority: -- → P3

They should be validated when set and when loaded. In addition to basic "is this URL valid" checks we should make sure the schemes make sense: http, https, file, about, moz-extension. Definitely no external protocol handlers, only things that are handled inside Firefox itself.

Keywords: sec-want
See Also: → CVE-2023-6871
See Also: → 1817262

We do have to allow at least some "about" urls of course (about:newtab is the default and about:blank is popular), but some are problematic. A bunch make no sense out of context but are harmless (e.g. about:blocked) and we tend to believe in letting curious people play around and learn from mistakes. But we should make sure we don't allow ones that could get the user stuck.

One we should consider blocking is about:crashparent, which will cause Firefox to immediately abort on start-up. It's not crucial that we block this since it is more recoverable than similar urls in other products: normally you immediately get the crash reporter dialog with an option to restart Firefox, and on restart it detects the crashes and offers to restore the last session. From there you can open preferences and change the home page. Even if it did get stuck in a crashing loop a knowledgeable user could find the profile prefs file and erase the home page, but that would be beyond most folks. If we do decide to block this one we should consider all about:crash*. The other ones we have don't currently seem to lead to any unrecoverable problems, but as we invent new kinds of processes we will no doubt create new about:crash<foo> urls, and maybe some process in the future wouldn't recover very gracefully from being killed on start-up.

You need to log in before you can comment on or make changes to this bug.