Blocking Top-Level Navigations to Data URLs for Firefox 58 | Hacker News Reader

Blocking Top-Level Navigations to Data URLs for Firefox 58

blog.mozilla.org

118 pointsmgliwka53 comments

Wouldn't it make more sense just to fix the URL bar to make data URIs look different? You could even go to the extreme of making it just show "data:…" and requiring you to put focus on it to find out the full URI.

No kidding... this is a problem they created by hiding/obfuscating the URL scheme. If the majority of URLs you visit start with http:// or https://, then data: stands out like the proverbial sore thumb.

That requires that you know what you're doing, though. Non-technical people are probably more inclined to think along the lines of "huh, odd, but everything looks fine, so it's probably my fault it looks like that"

In that case why bother with using a data url at all? They could just use "www.paypal.com.cgi-bin.webscr.xxxxxxxxx.myevilsite.com"

That way, they don't have to bother with a domain registration, either. A domain registration is neither free of charge nor entirely free of risk.

They could just create subdomains on a compromised domain they control belonging to someone else.

Did they hide it? I see "https://" in my Firefox.

They show https:// but they hide http://

Oh, I honestly would've missed this, because so few sites I browse are in cleartext anymore. They may as well just display a giant "INSECURE" banner, instead of http://, though.

They will, and they already do if that page includes a password form field :)

FWIW, this recently landed in Firefox Nightly:

security.insecure_connection_icon.enabled

security.insecure_connection_icon.pbmode.enabled

Though it's still disabled by default (currently the insecure connection icon is only shown if a password field is present on a http page / the form action url is http).

I'm glad they aren't blocking explicit entries. This morning I discovered I could quickly send snippets of text to my phone by writing it as a data uri and sending the tab via Fx sync.

That sounds heavily exploitable, in this age of crypto-currency-mining malware

It is you can embed any binary in a b64 string in the html page and then download it from within the browser.

Since the download happens locally it also will not be logged in your perimeter monitoring and most security appliances do not inspect inline HTML especially from “trusted” domains due to performance limitation.

I’ve used this trick to bypass DLP, local policies and various content filtering appliances multiple times.

On linux boxes, for small snippets I use 'qrencode -t ansi "message"' and use a QR scanner app to read the text to my phone...

I used to do exactly the same, but using a Firefox extension [0]. Since it is not compatible with quantum, I am writing my own, but it's still a prototype for now.

[0] https://addons.mozilla.org/en-US/firefox/addon/offlineqr/

That's cool! Do you know where I can find documentation of the "-t" option? The following is all I find, and I'm not sure what all the variants mean:

    -t {PNG,EPS,SVG,ANSI,ANSI256,ASCII,ASCIIi,UTF8,ANSIUTF8}
                 specify the type of the generated image. (default=PNG)

The only one i do not recognize in some way is EPS. The rest are either image formats(PNG, SVG), or various character encodings (all the rest).

> The only one i do not recognize in some way is EPS.

https://en.wikipedia.org/wiki/Encapsulated_PostScript

Alternatively for Android, you could enable KDE Connect[1] and copy the text to the clipboard (which will then be copied to the Android clipboard, and vice-versa). Or easily put it in a file and transfer it over to your device.

[1] - https://community.kde.org/KDEConnect

KDE Connect is one of the programs I can't live without anymore!

I use messaging apps for that.

Depending on how exactly this block works, it may break an important functionality of our application :/

We generate SVG graphs in the browser, and have a button with a data:image/svg+xml URL to allow users to download these graphs, for example to include in a publication.

You’re fine.

> Whereas the following cases will be allowed:

> • Downloading a data: URL, e.g. ‘save-link-as’ of “data:…”

That sounds like the user will have to right-click and choose "Save As"?

I presume the `download` attribute will still work, as it’s not navigation:

  <a href="data:image/svg+xml,…" download="filename.svg">

And that "I presume" instead of "I am quite certain" is precisely why I said I was worried about exactly how this block works. I will need to try with the beta, I suppose.

Hello! I work at Mozilla and am figuring out those exact particulars right now. Will update here when I figure out the final decision re: <a download>

I can confirm <a download> links with data: URIs will work after this change.

I built a test to demonstrate: https://data-uri-test.glitch.me/

Thanks for checking and the reassurance!

Hrm, I think this will block the only data uri I use: the 'this form' button on http://sprunge.us/

Yeah, the form on http://sprunge.us/ is blocked for me in Firefox 58.0b7, which is kind of annoying because I used it regularly. If this is a phishing problem, couldn't it be fixed by changing UI rather than breaking functionality?

Thank you so much for this mozilla. It is ridiculously easy to trick even tech savvy users with a data: uri phish.

Hopefully data:image/ still works for favicons. Embedding a highly compressible ~450 byte string in HTML is faster than issuing a new request, under most instances.

I’m not sure Firefox even uses favicons anymore but that definitely isn’t navigation so it isn’t blocked.

It does, not sure why you would think it doesn't? I do know chrome gets annoying about them, always requesting a sites favicon even when it doesn't have one listed in the document.

I haven’t seen them in the UI while I remember them being shown quite prominently. I wouldn’t really expect them to be used only for sites added to favorites because that’s a privacy issue.

Might be a setting in yours, or a plugin of some sort?

Your tabs don't show the favicon?

Note that it said "top level" navigation.

Does anyone have a (non-malicious) example of this sort of "attack"? I don't quite get it; some people are mentioning Javascript, but the description sounds more like a phishing, e.g. `data:text/html;base64,MyBank.com/account/xxxxx`

Presumably such leading junk is hidden in the rendered page, making the user think they're on MyBank.com?

>Presumably such leading junk is hidden in the rendered page, making the user think they're on MyBank.com?

it's even simpler than that, they add a bunch of spaces after the "fake" url to pad out the actual payload so it doesn't show in the urlbar. any issues with the page content can be fixed with document.write or whatever.

See https://twitter.com/tomscott/status/812265182646927361

The phishers are using a URL like `data:text/html,https://example.com/account/xxxxx (lots of spaces here) <script>/* phish phish phish */</script>`

You won't see that scary <script> in the URL unless your browser window is super-wide.

I know of a website that decrypts all its content clientside and uses this (i think) as a mechanism for a user to download his own attachments.

The Idea is that the whole website could be a static file somewhere and the webserver is only a key value store that has no idea what it is saving. Doesn't work that way currently because file:/// doesn't allow ajax calls to somewhere else but that's a solveable problem.

Generally, every download that gets generated clientside by the JS is hit by this

This does not affect downloads of data urls, only navigation to data urls.

> Opening “data:image/*” in top-level window, unless it’s “data:image/svg+xml”

Just curious-- why the exception for svg?

I think they block svg but not other images because svgs can contain javascript and could be used in a phishing attack.

i.e.

  data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><script>alert('hi')</script></svg>

Oh wow, even if you right-click "View Image" the script gets run.

Hm. But will I still be able to open them from the developer console...?

I'm trying to figure out if this will kill Bookmarklets (https://en.wikipedia.org/wiki/Bookmarklet)

Bookmarklets use javascript: urls, not data: urls.

So yeah I would have thought so too but am confused over the first few examples of "blocked" he gives...

Only some bookmarklets that go to a data URL on top level are affected. They should be easy to modify to open them inside an iframe or to replace the existing document instead.

Reply on news.ycombinator.com