7 ms·

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

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

xja 10y ago
That's a real shame. There are certainly things they could do to prevent images looking quite so similar to UI elements.
- willvarfar 10y ago
  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?
  - Mtinie 10y ago
    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.
  - tdkl 10y ago
    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.
    - xja 10y ago
      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.
      - gearhart 10y ago
        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.
  - xja 10y ago
    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.
    - das_keyboard 10y ago
      Why don't just put a little frame around embedded elements like pictures, etc? Maybe with a little icon indicating the type.
      - laumars 10y ago
        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.
        pavel_lishin 10y ago
        According to our numbers, plain emails actually perform better than HTML emails when it comes to business mailings.
        laumars 10y ago
        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.
  - deleted 10y ago
    [deleted]
  - swiley 10y ago
    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.
    - sethrin 10y ago
      > 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.
      - swiley 10y ago
        Emails had a form of markup before HTML emails came, it was the inspiration for markdown.
IanCal 10y ago
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?
- timruffles 10y ago
  Agreed - I think simply highlighting the data:... part of the URL with a vaguely scary colour would help.
  - mayoff 10y ago
    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” https://account.google.com” part of the URL and thus still mislead naive users.
    - eridius 10y ago
      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:// 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:// https:// part.
IshKebab 10y ago
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".
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- elastic_church 10y ago
  yeah but we all do this everyday to the designers
jneal 10y ago
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.
- contravariant 10y ago
  >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.
  - Jarwain 10y ago
    Why even render the content of data:text/html in the first place?
    - contravariant 10y ago
      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.
      - Jarwain 10y ago
        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?
Jarwain 10y ago
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
- grenoire 10y ago
  It's just not treated as an exception. Works for all MIME types supported by the browser.
  - babyrainbow 10y ago
    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?"
    - Hello71 10y ago
      that won't kill battery life at all
dschep 10y ago
A minor change that would help (a little) is to replace all spaces in the address bar with %20.
- sleepybrett 10y ago
  Or make the whole bar red and flashing whenever someone uses the tricks this attack uses. Specifically data.text/html and inline script tags.
- fsavard 10y ago
  Or some clearly visible icon at the end of the URL bar saying "2832 more characters ->".
Ajedi32 10y ago
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/...` https://accounts.google.com/...` the URL bar said `https://accounts.google.com.login.cz/...` https://accounts.google.com.login.cz/...` instead?

xja 10y ago

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

willvarfar 10y ago
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?
- Mtinie 10y ago
  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.
- tdkl 10y ago
  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.
  - xja 10y ago
    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.
    - gearhart 10y ago
      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.
- xja 10y ago
  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.
  - das_keyboard 10y ago
    Why don't just put a little frame around embedded elements like pictures, etc? Maybe with a little icon indicating the type.
    - laumars 10y ago
      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.
      - pavel_lishin 10y ago
        According to our numbers, plain emails actually perform better than HTML emails when it comes to business mailings.
        laumars 10y ago
        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.
- deleted 10y ago
  [deleted]
- swiley 10y ago
  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.
  - sethrin 10y ago
    > 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.
    - swiley 10y ago
      Emails had a form of markup before HTML emails came, it was the inspiration for markdown.

IanCal 10y ago

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?

timruffles 10y ago
Agreed - I think simply highlighting the data:... part of the URL with a vaguely scary colour would help.
- mayoff 10y ago
  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” https://account.google.com” part of the URL and thus still mislead naive users.
  - eridius 10y ago
    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:// 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:// https:// part.

IshKebab 10y ago

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

deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
elastic_church 10y ago
yeah but we all do this everyday to the designers

jneal 10y ago

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.

contravariant 10y ago
>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.
- Jarwain 10y ago
  Why even render the content of data:text/html in the first place?
  - contravariant 10y ago
    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.
    - Jarwain 10y ago
      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?

Jarwain 10y ago

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

grenoire 10y ago
It's just not treated as an exception. Works for all MIME types supported by the browser.
- babyrainbow 10y ago
  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?"
  - Hello71 10y ago
    that won't kill battery life at all

dschep 10y ago

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

sleepybrett 10y ago
Or make the whole bar red and flashing whenever someone uses the tricks this attack uses. Specifically data.text/html and inline script tags.
fsavard 10y ago
Or some clearly visible icon at the end of the URL bar saying "2832 more characters ->".

Ajedi32 10y ago

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/...` https://accounts.google.com/...` the URL bar said `https://accounts.google.com.login.cz/...` https://accounts.google.com.login.cz/...` instead?