3 ms·

The attacker could inject code that replaces the Stripe integration with something that looks identical to the end-user but harvests the CCs.

• shaneos 9y ago
  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
  • wahnfrieden 9y ago
    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?
    • antsar 9y ago
      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.
  • adbachman 9y ago
    The article addressed that objection, though. 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.