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

I've now consulted ChatGPT on a solution for a vulnerability which I even filed a patent for long time ago and I feel less stupid right now.

Say bank.com has SSL. Cool! Now how does Angular work? You visit angular-site.com/some/path and backend server rewrites the request to angular-site.com/index.html. You still see angular-site.com/some/path. And it works and that's how Angular servers that serve Angular apps work.

Now, what prevents bank-malicious-url.com from acting like a viewer, where it access bank.com when you visit it hence the SSL encryption/decryption is made between it and the legit bank.com, whilst malicious-bank.com url has a simple letsencrypt certificate that is showing you a not so legit green secured URL web address on the top of your web browser?

Please help! I abandoned my patent, I've been building my Angular web app and now I think that the old me was not so dumb after all. Where to proceed from now?

4 points | by vitalipom 3 hours ago

4 comments

alp1n3_eth 2 hours ago
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).
NetworkPerson 23 minutes 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.
efortis 2 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...
p_ing 3 hours ago
A CSP will prevent this.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
[-]
- vitalipom 3 hours ago
  Isn't CSP controlling what you can fetch FROM your website? The proxy in the example I mentioned can act as a simple web browser behind the scenes. Unless I'm missing something.
  [-]
  - p_ing 2 hours ago
    https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...
    Would be an additional method.
    Your attack is not new/novel.
    [-]
    - vitalipom 2 hours ago
      Not claiming it to be novel or new at all. Just trying to understand. I'll think about CORS. Meanwhile my thought - correct me if I'm wrong, is that CORS would be irrelevant since on behalf of bank.com it is simply controlled by a regular viewer. While the real user is just telling the proxy where to click and what to do.
      [-]
      - p_ing 2 hours ago
        CORS policy would say "okay end user, you can load everything from me, but also get jquery from <some jquery CDN>. no resources can come from anywhere else".
        It's not a bad idea to just put in a CSP (always put in a CSP!), CORS policy, and Same-Origin. This is configured on your app rather than server (usually).
        MDN is one of the better resources for this, and links out to other authoritative resources in the additional info section of a directive.
        [-]
        vitalipom 2 hours ago
        Okay, I’ll give it a try by mocking up an attack on a secure app of mine I’m making. Thanks!!!