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.

firefox 58 block navigation data url

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.
Read also:  What's in Store for Firefox in 2017?

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.

Summary
Article Name
Firefox 58 to block top-level data URL navigation
Description
Mozilla plans to block web pages from navigating the top-level window to a data URL in the upcoming Firefox 58 Stable version.
Author
Publisher
Ghacks Technology News
Logo
Advertisement
Please share this article

Facebooktwittergoogle_plusredditlinkedinmail



Responses to Firefox 58 to block top-level data URL navigation

  1. Marcin November 28, 2017 at 2:27 pm #

    It looks like a move in a good direction for our security.
    Thank you for the details, Martin.

  2. Franck November 28, 2017 at 3:05 pm #

    Yeah, looks good... thanks Martin !

  3. Privacy_Apprentice November 28, 2017 at 5:57 pm #

    Is there a way to accomplish now this with add-ons or user.js?

  4. Privacy_Apprentice November 28, 2017 at 5:58 pm #

    Is there a way to accomplish this now with add-ons or user.js settings?

  5. ams November 28, 2017 at 6:42 pm #

    For news items like this, it would be useful to know whether the change will also be applied in the forthcoming firefox-esr version.

    • Fx0 November 28, 2017 at 7:25 pm #

      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.

  6. User November 29, 2017 at 3:18 am #

    security.data_uri.block_toplevel_data_uri_navigations

    • John November 29, 2017 at 8:39 am #

      Thanks for this.

      I can confirm that's already true by default on Firefox 58 beta.

  7. amb November 29, 2017 at 10:32 am #

    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?

    • Ben November 29, 2017 at 11:37 am #

      Chrome cannot do that and thus FF cannot either.

    • Tom Hawack November 29, 2017 at 12:56 pm #

      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.

      • Pants November 29, 2017 at 1:17 pm #

        That has nothing to do with internal pages - it does however cover AMO

      • Tom Hawack November 29, 2017 at 2:03 pm #

        @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.

      • TelV November 29, 2017 at 3:07 pm #

        @ Tom Hawack.

        For AMO see: https://wiki.mozilla.org/AMO

        For "internal pages", see this Wikipedia article: https://en.wikipedia.org/wiki/Internal_link

      • Tom Hawack November 29, 2017 at 3:18 pm #

        @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.

      • Richard Allen November 29, 2017 at 3:26 pm #

        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.

      • Richard Allen November 29, 2017 at 3:39 pm #

        How could I forget the Library: bookmarks, history, downloads and the sidebars? SMH ;)

      • Tom Hawack November 29, 2017 at 3:52 pm #

        @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 :)

      • Richard Allen November 29, 2017 at 4:31 pm #

        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!

      • amb November 30, 2017 at 12:03 pm #

        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

      • Pants November 30, 2017 at 1:46 pm #

        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.

      • Tom Hawack November 30, 2017 at 2:21 pm #

        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.

  8. Gary November 30, 2017 at 10:03 am #

    Dose Firefox 57 ave the Classic Look, (Grey Menus of Windows 98) how is this done ?

Leave a Reply