35

From https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication, it says:

A potential security hole that has recently been fixed by browsers is authentication of cross-site images. From Firefox 59 onwards, image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialogs (bug 1423146), preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page.

How could user credentials be stolen? The authentication happens between the user and the image source website, while the "third-party page" website is not involved.

Anders
  • 64,406
  • 24
  • 178
  • 215
Rick
  • 1,027
  • 1
  • 8
  • 21
  • 4
    Related: [How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header?](https://security.stackexchange.com/q/54933/12) In my answer then I called it a 403 Phishing Attack, which was the common nomenclature then. Today it's more commonly referred to as an HTTP Basic Auth Phishing attack, or something similar. – Xander Sep 05 '19 at 04:04
  • 2
    As an aside, I've seen this attack in the wild, on a website that I had some level of responsibility for. – Xander Sep 05 '19 at 04:07
  • Because the user will enter the credentials for the "third-party page", because that's the page they're on. – OrangeDog Sep 06 '19 at 15:48

1 Answers1

47

As outlined in the bug report, the issue is that an authentication dialog shows up on trustworthy.com, so oblivious users (and let's be honest, many users who pay attention as well) will type in their username and password, not realizing they're actually sending it to malicious.com. Combine this with a very similar looking domain (e.g. trustw0rthy.com), and the only reason a user wouldn't give away their credentials is because they've never seen trustworthy.com use Basic Auth before and it made them suspicious.

As an example:

Let's say your online banking at bank.com requires you to log in via Basic Auth. Now the attack would work like this:

  • An attacker manages to embed his image, served from malicious.com, somewhere in bank.com where the user (you) will load the image.
  • You load the page on bank.com that embeds the attacker's image, and the browser pops up a Basic Auth dialog.
  • You type in your username and password for bank.com, believing the site is asking you to log in, but the browser will send them to malicious.com instead.
chrki
  • 105
  • 3
AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
  • 8
    Ahhh I see! It's for example like `bank.com` requires Basic Auth like usual, and the attacker manages to embed his image somewhere in `bank.com` where the user would load the image. Then the user would type in the username and password as if it were the auth dialog from `bank.com`. – Rick Sep 05 '19 at 04:11
  • @Rick: Precisely. I edited your example into the answer. Hope you (and AndrolGenhald) don't mind. – sleske Sep 05 '19 at 12:07
  • @sleske Ah no problem ;) – Rick Sep 05 '19 at 13:15
  • So showing the domain name in the modal prompt (like every browser but IE6 does it) is not enough because of homoglyph attacks? – Bergi Sep 05 '19 at 18:26
  • 7
    @Bergi Showing the domain name might help, but it still relies on the user noticing it, comparing it to the correct domain for the site they intended to visited, and knowing not to enter their credentials if there's a mismatch. I haven't seen any user test data, but it strikes me as likely that even without using homoglyph trickery, a substantial number of users will still provide their credentials in that situation. – Zach Lipton Sep 05 '19 at 20:34
  • 2
    A better example than `bank.com` might be a site like Stack Exchange or forum/BB/etc. that allows embedding links to arbitrary off-site images in user-generated content. Webmail would also be a major target if there are still webmail providers that let third-party resources through. – R.. GitHub STOP HELPING ICE Sep 05 '19 at 20:39
  • 4
    @R.. If this vulnerability wasn't already fixed a malicious/compromised CDN could probably target a good portion of the internet. – AndrolGenhald Sep 05 '19 at 20:47
  • 7
    A more realistic attack would be a user making a post on `forum.com` that embeds an image, and then using the collected username/password pairs to try to log in to `bank.com`. – Mark Sep 05 '19 at 22:24
  • 1
    @Bergi People generally don't understand URLs. Remember when there was that blog post that happened to end up in first place in google search on "Facebook" and suddenly people were like "omg, you hacked Facebook, I want to go to Facebook and end up on your site!"? :D – Luaan Sep 06 '19 at 09:09
  • so, is this issue still affected in chrome, opera...etc.. browsers? – T.Todua Sep 06 '19 at 10:32