True, but this is easily detected. It’d have to provide tokens to the page, which would fail 100% of the time when sent to the Stripe API. These types of attacks are really only effective when difficult to detect, and therefore allowed to run for more than a very short time
1. Only activate on sessions where it’s never activated before.
2. Only activate one in, say, seven times.
3. Sniff form once, fail to submit, show user "unexpected error, try again", allow normal behavior, success, user moves on
4. pull the numbers
It’s nice to imagine we follow up every single JS or user reported “it fails sometimes?” error, but a clever malicious script author knows we don’t check 100% of the time.
We are required to expect transient and potential errors from third party services, not even Stripe has 100% uptime. This kind of theft looks like a transient and unexplainable error.
The Stripe frames are set up by JS. What’s stopping an attacker from wrapping it in their own form, collecting, and having it still submit the details to Stripe?
The attacker's code isn't hosted on Stripe's domain. It could render the real Stripe iframe, but could not interact with it (ie. populate form values and submit).
An attacker could try to POST the values directly to Stripe instead, but Stripe presumably uses CSRF-prevention techniques (eg. a token in the form) to stop this as well.
