Firefox 58 to block top-level data URL navigation
Mozilla plans to block web pages from navigating the top-level window to a data URL in the upcoming Firefox 58 Stable version.
The new stable version of the web browser will be released on January 23, 2018 according to the Firefox release schedule.
The change has found its way in development versions of the Firefox web browser such as Firefox Nightly already.
Christoph Kerschbaume, Content Security Tech Lead at Mozilla, notes on the official Mozilla Security blog that data URLs are used by malicious actors to trick users.
However, most end users are not aware of the concept of a data URL which can contain a legitimate address string making the end user believe they are browsing a particular web page. In reality, attacker provided data URLs can show disguised content tricking end users into providing their credentials.
Mozilla will block web pages from navigating the top-level window to data URLs to protect Firefox users from phishing attacks that abuse data URLs in Firefox 58.
The organization distinguishes between data URL scenarios that are blocked in Firefox 58, and scenarios that are not.
The following cases are blocked in Firefox 58 and newer versions of the web browser:
- Navigation to a top-level data URL using: window.open, window.location or links.
- Redirections to a new top-level data URL using 302 redirects, meta refresh redirects.
- External programs that try to open data URLs in the web browser.
Firefox 58 won't block the following data loading scenarios:
- When the user enters or pastes data: into the address bar.
- When plain text data files are opened.
- When data:image is opened in top-level windows, unless it is data:image/svg+xml.
- When data:application/pdf or data:application/json are opened.
- When data is downloaded.
Firefox displays a log entry in the console whenever a data request is blocked in the browser. You can load the Console with the shortcut Ctrl-Shift-K, or by tapping on the F12 key, and switching to Console when the Developer Tools interface opens in the browser.
Google Chrome and other Chromium-based web browsers block access to data URLs already as well.
Just went to the Daily Mail site and it would appear that they’re using data images now whereby just a blank box appears where the image should be. Right clicking it –> View Image Info reveals that they’re all data images now: https://imgur.com/a/vNNLW
I’m using Basilisk at this particular moment though so I guess they’re following Moz’s lead.
Actually i wish i can disable DATA: uri completely for all cases its used, because currently its only problem – a lot of sites started to use them to put ads, since they pass various adblocking lists.
Dose Firefox 57 ave the Classic Look, (Grey Menus of Windows 98) how is this done ?
little digression here… is it possible to make extensions work on Fox’s internal pages somehow? i know chrome can do that… i don’t mind messing with it’s integral files. any tips?
I’m running Waterfox 55 so I cannot confirm the following :
I’ve read that starting Firefox 57 there’s a hidden setting that handles that :
// enable Firefox WebExtensions on Mozilla websites
user_pref(“privacy.resistFingerprinting.block_mozAddonManager”, true); // (hidden pref) (FF57+)
If it does work, thanks for confirmig.
Well, thanks for that sum of information, Pants. We’re really digging in the browser’s core at this point.
More and more settings in proportion of a non-stop browser complexity increase, but settings available nevertheless and fortunately.
see this: https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/AddonManagerWebAPI.cpp#44
mozAddonManager API is all about addons, you can also flip a pref “extensions.webapi.testing” to extend those sites “whitelisted”, but by default it is only 3 sites, of which AMO is the only one you care about. It may be that this will be used in future to determine your Firefox version when you visit AMO because privacy.resistFingerprinting breaks the download flow – but nothing has been decided. BE aware that is supposedly a very very very tiny risk of silent installs via AMO if .. IF .. you have a rogue extension(?) already installed, it can now inject rogue scripts on the page .. AND … you allow service workers – which means you can be fubared, or something – f*d if I know. To mitigate that you can set the following
/* 2610: remove special permissions for certain mozilla domains (FF35+)
* [1] resource://app/defaults/permissions ***/
user_pref(“permissions.manager.defaultsUrl”, “”);
Now AMO is no more dangerous than any other web page
With the block_mos pref AMO is no longer “privileged content” and behaves like a normal web page and you can use your gestures, styles, uBo & uMatrix blocks etc – have fun. And with the 2610 pref it no longer has special powers re installing addons
about-scheme, behind-the-scene, chrome-extension-scheme, chrome-scheme, moz-extension-scheme … etc, are internal – there is no way you can use extensions on them. You can of course use userChrome* trickery and autoconfig. There will be no hidden pref to flip this – it has been designed this way deliberately.
Internal pages — example is about:newtab — where gestures cannot get triggered
Okay, seems that it’s not possible at the moment. Hopefully there will be hidden about:config setting for that.
@Ben
what chrome internals has to do with firefoxs? You are confusing something… also:
chrome://flags/#extensions-on-chrome-urls
I’m not completely understanding “privacy.resistFingerprinting.block_mozAddonManager” myself. When setting it to true in FF 57 I’m getting navigator.mozAddonManager “is undefined” in the browser console and then when the setting is set to false I see “permissionPromptsEnabled” . But either way I still get asked if I want to “Add” the extension when clicking on “Add to Firefox”. Maybe it’s just preventing Mozilla from fingerprinting your browser configuration? Curiouser and curiouser!
@Richard Allen, well that’s what I’ve always had in mind!
“internal pages is everything listed on the about:about page: about:cache, about:config, about:preferences, about:support and so forth.” … including the Reader-Mode rendered pages.
So when Pants writes that
user_pref(“privacy.resistFingerprinting.block_mozAddonManager”, true); // (hidden pref) (FF57+)
“has nothing to do with internal pages – it does however cover AMO”
he does mean that the setting applies only to AMO, OK. Now I just have to find out what exactly this setting does. I obviously totally misunderstood this setting as I thought it would enable Webextensions on *all* pages, be they AMO, be they “internal pages” …
I’m far from knowing everything but I doubly suffer when what I have in mind is unclear!!
Ouf, ouf! Thanks, Richard :)
How could I forget the Library: bookmarks, history, downloads and the sidebars? SMH ;)
AMO is just the Mozilla add-ons website. AMO=addons.mozilla.org
internal pages is everything listed on the about:about page: about:cache, about:config, about:preferences, about:support and so forth.
@TelV, copy/pasted, thanks.
I could have searched myself as I do most of the time, other things/higher priorities defeated that.
I’ll start digging into that now.
@ Tom Hawack.
For AMO see: https://wiki.mozilla.org/AMO
For “internal pages”, see this Wikipedia article: https://en.wikipedia.org/wiki/Internal_link
@Pants, OK
I went to download/have a look at your ghacks-user.js-57.0-alpha user.js file and indeed it lists :
/* 4503: disable mozAddonManager Web API (FF57+)
* [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1384330 ***/
// user_pref(“privacy.resistFingerprinting.block_mozAddonManager”, true); // (hidden pref)
I’m confused by what is meant by AMO and by “internal pages”. I guess what we are all striving for is to have Webextensions run on all pages, those (“internal pages”?) where they are blocked included. For instance I use a lot a Webextension called ‘ScrollAnywhere’ but not only will it not run on AMO pages but as well on Web pages when those are viewed in Firefox’s ‘Read Mode’ (is ‘Read Mode’ an “internal page”?) A pain for that extension as with all other Webextensions. uBO itself won’t make it on AMO as on “internal pages” … but uBO “firefox extension” (legacy) of course does.
Maybe the opportunity to ask you your clarification on this topic. Thanks.
That has nothing to do with internal pages – it does however cover AMO
Chrome cannot do that and thus FF cannot either.
security.data_uri.block_toplevel_data_uri_navigations
Thanks for this.
I can confirm that’s already true by default on Firefox 58 beta.
For news items like this, it would be useful to know whether the change will also be applied in the forthcoming firefox-esr version.
It will be in the next feature update of Firefox ESR, of course. This means Firefox ESR 59, not Firefox ESR 52. There are never new security features in an ESR point release, only security and bug fixes.
Is there a way to accomplish this now with add-ons or user.js settings?
Is there a way to accomplish now this with add-ons or user.js?
Yeah, looks good… thanks Martin !
It looks like a move in a good direction for our security.
Thank you for the details, Martin.