Hacker News new | past | comments | ask | show | jobs | submit
akersten | on: Restaurant Delivery Payment-Skimming Campaign
Despite mountains of text on this page, none of it explains how exactly this "reverse proxy" of the restaurant's site actually works?

Is it just some JS on bad.com shuttling assets from the real site and displaying them on the fake one? Shouldn't the right CORS headers from the real site prevent this?

Is it a real browser running on a server somewhere visiting the real site, and then rendering that output on a <canvas> on the fake site to avoid the browser's built in protections against this kind of thing? And throwing up their own credit card entry form when the time is right?

Maybe the answer's in there somewhere. Too much Claudish to parse through.

mik3y | parent
The evil site is acting as a reverse HTTP proxy: When you do a `GET evilsite/foo`, to compose its response the server first does a `GET targetsite/foo`, mutates the response however it likes, and passes it along to you.

So you don't need to worry about CORS from the perspective of the web app, nor need a real browser, because the victim is only ever interacting with the evilsite endpoints.

Certainly there are ways the target site could try to thwart this (i.e. detect unusual request patterns from wherever the proxy server is fetching from; client-side JS to detect the site being hosted on a foreign domain; etc). But at that point it's an arms race.