Hacker News Reader

Comment by timruffles | Hacker News Reader

I reported this a back in March 2016, and Google said it was not an issue.

Analysed whole attack here: https://gist.github.com/timruffles/5c76d2b61c88188e77f6

This was the response I got:

> The address bar remains one of the few trusted UI components of the browsers and is the only one that can be relied upon as to what origin are the users currently visiting. If the users pay no attention to the address bar, phishing and spoofing attack are - obviously - trivial. Unfortunately that's how the web works, and any fix that would to try to e.g. detect phishing pages based on their look would be easily bypassable in hundreds of ways. The data: URL part here is not that important as you could have a phishing on any http[s] page just as well.

View on HN

Ah the classic "ugh. we don't want to have to fix this, so here are some bullshit technical reasons why it's impossible and a bad idea".

yeah but we all do this everyday to the designers

I'd say the data: url part is important, as it lets you construct much more plausible looking contents for the address bar. The standard "check it's google.com" would probably fail for a lot of people.

How many people really know that you can put a whole webpage in the URL?

Agreed - I think simply highlighting the data:... part of the URL with a vaguely scary colour would help.

Apple's approach in Safari is to only show the hostname in the address bar, unless the address bar has focus. This works pretty well in general (for non-power-users). Unfortunately, for a data URL, it just shows as much of the URL as fits. This may well include the phony “https://account.google.com” part of the URL and thus still mislead naive users.

At the very least it'll still look different, which might hopefully make the user take a closer look. For example, for normal URLs, you never seen the https:// part (unless the address bar has focus). Even if you enable the advanced preference to show the full website address again, it still hides the https:// part.

This is pretty scary. When you hear security professionals explain to laymen how to identify phishing attacks, it's almost always check the URL, make sure you're actually at google.com and not go0gle.com, or something like that.

I can't even imagine what legitimate use there is to placing an entire HTML document into the URL. Just seems like a hack someone came up with as a solution to a problem, not the right solution, but a solution nonetheless.

>I can't even imagine what legitimate use there is to placing an entire HTML document into the URL. Just seems like a hack someone came up with as a solution to a problem, not the right solution, but a solution nonetheless.

It allows you to embed data in an URL, meaning you can link to documents that aren't necessarily stored anywhere, such as generated images/text.

I suppose you could make an argument that it shouldn't be shown as a regular URL.

Why even render the content of data:text/html in the first place?

Because that's precisely what the 'data:' URI is supposed to do. The URI is only a description of some resource, there's no reason one description should be treated differently than any other, unless it's actually pointing to a different resource.

Its more the idea of rendering the HTML code in this fashion does not make sense to me. Maybe print the code to the page instead of rendering it. Anything would be better than rendering the code; I can't even come up with a possible use case for that functionality, can you?

You could generate a webpage and link to it without needing to host it somewhere.

At any rate, if you allow a URI scheme that embeds the data in the URI itself it'd be very odd to arbitrarily restrict the valid MIME types. It'd be like forbidding a http URL from linking to a JPEG.

Well in a way you're just offloading the cost of hosting that code/data in that case. Instead of hosting it yourself, the page with the link is hosting that webpage.

Well it wouldn't really be arbitrary, it'd be specifically HTML and/or JS, for security related purposes.

To give an example, I've seen some multiplayer games with dynamic content, that use Websockets for communication with the server and update various information via data URIs. I've never seen a text/html data URI yet (mostly image transmission to be honest) but for a multi-client Websockets type application I definitely wouldn't rule out that sort of thing.

I agree that blocking the rendering of data:text/html (and any other MIME type that could be used maliciously) from the address bar is a good idea. I can't think of a valid use case for that scenario. It seems like similar attack vectors have been known for some time (https://nakedsecurity.sophos.com/2012/08/31/phishing-without...).

Not to mention don't blobs allow us to do this now anyway?

make sure you're actually at google.com and not go0gle.com

And how about the domain with a character that looks more like 'o' than '0'? There was something on HN recently about that. The example given would have completely fooled me, since it looked the same as the real domain.

https://en.m.wikipedia.org/wiki/IDN_homograph_attack is what you're referencing, I believe :)

Interesting enough, HN itself was actually susceptible to this and it was reported by a security researcher:

https://news.ycombinator.com/security.html

Why is data:text/html even valid or rendered to the page in the first place? I'm having trouble coming up with a valid usecase for this

It's just not treated as an exception. Works for all MIME types supported by the browser.

Why not just alert the user if the address bar contain something weird like this...

And also, why not do something like this even. Let the browser save screen shots of some user selected sites. Like mail login page, online banking login page etc etc and have them map to a trusted url.

After loading a page, browser should screenshot the page and use some ML magic to compare it to the stored screenshots (I mean, there are things today that can call out the names of the things in an image and even what tell they are doing, right?). When one of them matches and If the url of the current page differs from the trusted url, the user should be alerted..Something like "Hey user, this page suspiciously looks like this page that we stored, but the url is completely different. Are you sure about this?"

that won't kill battery life at all

A minor change that would help (a little) is to replace all spaces in the address bar with %20.

Or make the whole bar red and flashing whenever someone uses the tricks this attack uses. Specifically data.text/html and inline script tags.

Or some clearly visible icon at the end of the URL bar saying "2832 more characters ->".

I mean, they're not wrong are they? Would this attack have been any less effective if instead of `data:text/html,https://accounts.google.com/...` the URL bar said `https://accounts.google.com.login.cz/...` instead?

That's a real shame. There are certainly things they could do to prevent images looking quite so similar to UI elements.

And stop people emailing screen shots?

The best approach I can come up with after five seconds thought is disabling links on non-text elements.

And then they go make an anchor that is whitespace over top of a background image... so we'd also need to disable links on large expanses of empty whitespace in text when its embedded in a mail.

I should think that can likely be worked around too, however. Got any more ideas?

For an "ultra security mode" that would work, but it would break a large portion of the Web's sites (as you noted, and it's easy-ish to circumvent) :/

Conceptually I like the idea of an ultra security mode for certain use cases, but ultimately it ends up making the whole web look like a bunch of plain text emails -- no JS, probably no images (unless the are somehow sandboxed and displayed from a safe local store), links are fully visible, etc.

Yeah, more people needs to get scammed, then the media will advertise how it happened and how to prevent it. It's called learning and is a sign of maturity.

To be frank I think that's a bit naive.

These attacks are a numbers game. There's a low cost to sending the emails and a much larger payoff.

Education helps, but it's still possible to catch people off guard, tired, new users etc.

Anything that can be done to flag these emails as spam, or increase the cost to the attacker helps.

Whilst I agree with you that the issue should be addressed by mail clients, these emails are not a numbers game in quite the same way as usual spam.

Since they rely on attachments and subject lines that are drawn from an individual user's gmail account, they have to propagate through a network, and they can't be just mass-emailed. Anything that can get the ratio of people falling for this lower than 1/<avg addressbook size> will completely eliminate the issue.

I was think more of a specific mail scanning process for images that look exactly like UI elements, with some fuzzy match.

If it matches, flag it with the usual warnings.

It feels like there's at least the potential to explore options.

Why don't just put a little frame around embedded elements like pictures, etc? Maybe with a little icon indicating the type.

That would break more legitimate HTML e-mails than the phishing it's aiming to catch. You might argue that it's worth the breakage but that would be a harder argument to sell to businesses.

Pragmatically I think Browsers disabling the rendering of data:text/html is a better approach. The breakage is minimal and it would catch more phishing attacks than just ones that originated from emails with images embedded.

According to our numbers, plain emails actually perform better than HTML emails when it comes to business mailings.

That's good to read but sadly that's a different point to the one I was making. Google would break a lot of legitimate emails if they make the changes to GMail that the GP was proposing. This would be an unattractive solution to Google as they are effectively breaking their "mail client" (in the broader sense of the term) in relation to their competitors and the benefits are limited to a specific type of phishing attack. So when Google way up the risk of annoying their customer base vs the securing them: this particular fix is unlikely to score high enough in the latter category to be worth the risk to the former.

Break the image into several layers and use transparency for the non-included bits. Or you could go full Acid2-like crazy CSS to generate the image from multiple, apparently innocuous elements.

Far better would be to not render HTML emails at all. They're an abomination and have always been causing security problems of different kinds.

> All programs will attempt to expand until they can render HTML emails. Those that cannot will be replaced by those that can.

More seriously, the expectation that emails will consist only of plain text is simply untenable. From a security standpoint this is obviously not ideal, but security and usability are opposed, and if your security scheme does not allow users to send documents with some form of markup, it will not be widely used.

Emails had a form of markup before HTML emails came, it was the inspiration for markdown.

Reply on news.ycombinator.com