Ask HN: What prevents the following vulnerability I found from being exploited?

vitalipom | 4 points

I think I understand the situation correctly, but please correct me if I'm wrong. You're essentially asking "How does realBank.com stop fakeBank.com from sending requests on behalf of the user to realBank.com"?

The malicious site could go about a few ways of potentially using functionality based on what protections the real bank's site is using. If it's not protected against CSRF & JWTs aren't in use, it could send a request on behalf of the user.

If the bank's site allows framing, a clickjacking attack could occur.

---

From your further comments though, it also sounds like you may be talking about phishing. There are several PoCs and real-world examples of attackers hosting a fake login page for Microsoft/Apple/Facebook and interacting in real-time with the real site. This allows them to also prompt the user for an MFA code which they'll use to authenticate.

If it's this phishing scenario, there's not a big way to block these for completely public-facing sites. Anything behind a VPN / whitelist would be impossible though (ofc).

alp1n3_eth | a day ago
[deleted]
| 17 hours ago

my-bank.com backend replays requests to bank.com

Yes, that’s a phising technique. CORS, CSP, or CSFR tokens can’t prevent it.

---

bank.com can mitigate it by blocking my-bank.com IPs

---

This 2007 paper [1] is about the initial mitigation idea, which was using Extended Validation Certificates (EV SSL). The study showed that users didn't pay attention to the special UI address bar EV certs had. In 2018 Chrome removed that UI style [2]

[1] http://www.usablesecurity.org/papers/jackson.pdf

[2] https://www.ghacks.net/2018/05/18/google-chrome-removal-of-s...

efortis | 2 days ago

Honestly, I think less attackers go this route than a simple clone of the target website and logging of credentials people enter. Much easier phishing than trying to interact with the real website. Saw this for a bank recently and sent an abuse email to the phishing domain’s registrar. Maybe 4 hours later and the registrar had killed it.

NetworkPerson | a day ago

That's a regular MitM attack, just with, specifically, Angular. If you can convince someone to go to malicious-bank.com and log into it with their real credentials, you've successfully phished them. If you go a step further and show them the real information from the real website, thats going a step further, but by then it's game over already.

If the attacker's already convinced you to give them your username/password (and 2fa), why bother showing the victim a fake (Angular) website?

A password manager/passkey/yubikey protects against this by checking that the url is bank.com and not malicious-bank.com, but unsophisticated users fall for this attack every day.

fragmede | 17 hours ago