Why would image resources loaded from different origins triggering HTTP authentication dialogs be harmful?How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header?
Elliptic curve commitments mod p
How to remove SQL Server Error Logs
Why does Greedo say "Maclunkey" in the Mos Eisley Cantina?
Homomorphism of composition to additive structure
How can I improve combat so my players don't always use the strategy of collectively focusing fire on one enemy at a time until it's dead?
Can the Protection fighting style be used in this way?
Names of all the spacecrafts on the art by Philippe “Manchu" Bouchet
How to break a equation with a single "summation symbol (sum) " common?
How can I add an ammeter and/or voltmeter to my home breaker panel?
Insets around a clock
Beautiful planar geometry theorems not encountered in high school
Days in indexed month
Bash script that shows changing real time values from commands
Stack data structure in python 3
What does the Node2D transform property do?
Where does the budget surplus of a conference go?
Maple root buckling patio pavers
TSP with revenue maximization
Did Ohio pass a law granting students the right to give scientifically wrong answers consistent with their religious beliefs?
NP-hard problems but only for n≥3
Does toddler keep hands around private parts?
Is there a heavy usage of the word "bonfire" in English?
What exactly is "Japanese" Salt and Pepper?
Using characters to delimit commands (like markdown)
Why would image resources loaded from different origins triggering HTTP authentication dialogs be harmful?
How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;
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.
http-basic-auth
edited Sep 5 at 8:43
Anders
53.9k22 gold badges149 silver badges180 bronze badges
asked Sep 5 at 3:37
RickRick
8261 gold badge6 silver badges18 bronze badges
add a comment
|
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.
http-basic-auth
edited Sep 5 at 8:43
Anders
53.9k22 gold badges149 silver badges180 bronze badges
asked Sep 5 at 3:37
RickRick
8261 gold badge6 silver badges18 bronze badges
4
Related: How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header? 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 5 at 4: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 5 at 4:07
Because the user will enter the credentials for the "third-party page", because that's the page they're on.
– Stop Harming Monica
Sep 6 at 15:48
add a comment
|
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.
http-basic-auth
edited Sep 5 at 8:43
Anders
53.9k22 gold badges149 silver badges180 bronze badges
asked Sep 5 at 3:37
RickRick
8261 gold badge6 silver badges18 bronze badges
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.
http-basic-auth
http-basic-auth
edited Sep 5 at 8:43
Anders
53.9k22 gold badges149 silver badges180 bronze badges
asked Sep 5 at 3:37
RickRick
8261 gold badge6 silver badges18 bronze badges
edited Sep 5 at 8:43
Anders
53.9k22 gold badges149 silver badges180 bronze badges
asked Sep 5 at 3:37
RickRick
8261 gold badge6 silver badges18 bronze badges
edited Sep 5 at 8:43
Anders
53.9k22 gold badges149 silver badges180 bronze badges
edited Sep 5 at 8:43
Anders
53.9k22 gold badges149 silver badges180 bronze badges
edited Sep 5 at 8:43
Anders
53.9k22 gold badges149 silver badges180 bronze badges
53.9k22 gold badges149 silver badges180 bronze badges
asked Sep 5 at 3:37
RickRick
8261 gold badge6 silver badges18 bronze badges
asked Sep 5 at 3:37
RickRick
8261 gold badge6 silver badges18 bronze badges
asked Sep 5 at 3:37
RickRick
8261 gold badge6 silver badges18 bronze badges
8261 gold badge6 silver badges18 bronze badges
4
Related: How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header? 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 5 at 4: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 5 at 4:07
Because the user will enter the credentials for the "third-party page", because that's the page they're on.
– Stop Harming Monica
Sep 6 at 15:48
add a comment
|
4
Related: How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header? 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 5 at 4: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 5 at 4:07
Because the user will enter the credentials for the "third-party page", because that's the page they're on.
– Stop Harming Monica
Sep 6 at 15:48
4
4
Related: How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header? 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 5 at 4:04
Related: How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header? 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 5 at 4:04
2
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 5 at 4:07
As an aside, I've seen this attack in the wild, on a website that I had some level of responsibility for.
– Xander
Sep 5 at 4:07
Because the user will enter the credentials for the "third-party page", because that's the page they're on.
– Stop Harming Monica
Sep 6 at 15:48
Because the user will enter the credentials for the "third-party page", because that's the page they're on.
– Stop Harming Monica
Sep 6 at 15:48
add a comment
|
1 Answer
1
active
oldest
votes
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 inbank.comwhere the user (you) will load the image. - You load the page on
bank.comthat 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 tomalicious.cominstead.
edited Sep 5 at 14:23
chrki
1053 bronze badges
answered Sep 5 at 3:58
AndrolGenhaldAndrolGenhald
14.4k5 gold badges39 silver badges45 bronze badges
8
Ahhh I see! It's for example likebank.comrequires Basic Auth like usual, and the attacker manages to embed his image somewhere inbank.comwhere the user would load the image. Then the user would type in the username and password as if it were the auth dialog frombank.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 thanbank.commight 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 onforum.comthat embeds an image, and then using the collected username/password pairs to try to log in tobank.com.
– Mark
Sep 5 at 22:24
|
show 5 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f216569%2fwhy-would-image-resources-loaded-from-different-origins-triggering-http-authenti%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 inbank.comwhere the user (you) will load the image. - You load the page on
bank.comthat 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 tomalicious.cominstead.
edited Sep 5 at 14:23
chrki
1053 bronze badges
answered Sep 5 at 3:58
AndrolGenhaldAndrolGenhald
14.4k5 gold badges39 silver badges45 bronze badges
8
Ahhh I see! It's for example likebank.comrequires Basic Auth like usual, and the attacker manages to embed his image somewhere inbank.comwhere the user would load the image. Then the user would type in the username and password as if it were the auth dialog frombank.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 thanbank.commight 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 onforum.comthat embeds an image, and then using the collected username/password pairs to try to log in tobank.com.
– Mark
Sep 5 at 22:24
|
show 5 more comments
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 inbank.comwhere the user (you) will load the image. - You load the page on
bank.comthat 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 tomalicious.cominstead.
edited Sep 5 at 14:23
chrki
1053 bronze badges
answered Sep 5 at 3:58
AndrolGenhaldAndrolGenhald
14.4k5 gold badges39 silver badges45 bronze badges
8
Ahhh I see! It's for example likebank.comrequires Basic Auth like usual, and the attacker manages to embed his image somewhere inbank.comwhere the user would load the image. Then the user would type in the username and password as if it were the auth dialog frombank.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 thanbank.commight 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 onforum.comthat embeds an image, and then using the collected username/password pairs to try to log in tobank.com.
– Mark
Sep 5 at 22:24
|
show 5 more comments
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 inbank.comwhere the user (you) will load the image. - You load the page on
bank.comthat 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 tomalicious.cominstead.
edited Sep 5 at 14:23
chrki
1053 bronze badges
answered Sep 5 at 3:58
AndrolGenhaldAndrolGenhald
14.4k5 gold badges39 silver badges45 bronze badges
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 inbank.comwhere the user (you) will load the image. - You load the page on
bank.comthat 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 tomalicious.cominstead.
edited Sep 5 at 14:23
chrki
1053 bronze badges
answered Sep 5 at 3:58
AndrolGenhaldAndrolGenhald
14.4k5 gold badges39 silver badges45 bronze badges
edited Sep 5 at 14:23
chrki
1053 bronze badges
edited Sep 5 at 14:23
chrki
1053 bronze badges
edited Sep 5 at 14:23
chrki
1053 bronze badges
1053 bronze badges
answered Sep 5 at 3:58
AndrolGenhaldAndrolGenhald
14.4k5 gold badges39 silver badges45 bronze badges
answered Sep 5 at 3:58
AndrolGenhaldAndrolGenhald
14.4k5 gold badges39 silver badges45 bronze badges
answered Sep 5 at 3:58
AndrolGenhaldAndrolGenhald
14.4k5 gold badges39 silver badges45 bronze badges
14.4k5 gold badges39 silver badges45 bronze badges
8
Ahhh I see! It's for example likebank.comrequires Basic Auth like usual, and the attacker manages to embed his image somewhere inbank.comwhere the user would load the image. Then the user would type in the username and password as if it were the auth dialog frombank.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 thanbank.commight 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 onforum.comthat embeds an image, and then using the collected username/password pairs to try to log in tobank.com.
– Mark
Sep 5 at 22:24
|
show 5 more comments
8
Ahhh I see! It's for example likebank.comrequires Basic Auth like usual, and the attacker manages to embed his image somewhere inbank.comwhere the user would load the image. Then the user would type in the username and password as if it were the auth dialog frombank.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 thanbank.commight 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 onforum.comthat embeds an image, and then using the collected username/password pairs to try to log in tobank.com.
– Mark
Sep 5 at 22:24
8
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
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
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
@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
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
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
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
@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
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
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
|
show 5 more comments
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f216569%2fwhy-would-image-resources-loaded-from-different-origins-triggering-http-authenti%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
Related: How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header? 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 5 at 4: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 5 at 4:07
Because the user will enter the credentials for the "third-party page", because that's the page they're on.
– Stop Harming Monica
Sep 6 at 15:48