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.

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.
  • 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 5 at 4:11
  • 6
    @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 5 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.. Sep 5 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 5 at 20:47
  • 6
    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 5 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.