[phsau]

Isnt't that what CORS/same-origin policies prevent? The attacker domain can be prevented from loading the bank resources within the same context by the browser. If the request is made by the attacker domain instead and proxied to you, then it doesn't have your cookies to display the private identification.

In either case, the "correct profile picture" would not load.

[thaumasiotes]

> If the request is made by the attacker domain instead and proxied to you, then it doesn't have your cookies to display the private identification.

Why is that a concern? You try to log in on a phishing site. The phishing site tries to log in as you at your bank's actual website. Your bank sends the phishing site your picture. The phishing site displays your picture to you.

[folmar]

The bank can and will use quite sophisticated request flow analysis to prevent one party from making too many attempts, so this means an attacker must grab a botnet or similar and be careful to avoid detection.

[GauntletWizard]

Most people would not question having to type in their username for a fresh login - Banks sign you out so quickly and their "remember me" is often intentionally gimped. So users are trained to type their username into the field, and the bad site can proxy that to the bank and send back the image just fine.

Okta still includes this "feature" by default, and is among the reasons I will never trust Okta or any client of theirs.

[tialaramex]

You can keep iterating on this if you like, and some banks did, but ultimately the bad guy has the exact same information you've presented to the bank to get this "correct profile picture". Cookies. CORS headers. None of that matters. If you get the "correct profile picture" so does the bad guy and then they just forward it to you.

We already know how to actually solve this problem. WebAuthn.