3 ms·

while this post is about the more general attack vector, its worth pointing out that if you use a modern credit card tool like Stripe Elements it is impossible

while this post is about the more general attack vector, its worth pointing out that if you use a modern credit card tool like Stripe Elements it is impossible to steal credit card numbers as they are embedded in an iframe and your page just gets a token that is meaningless to anyone else

Qerub 9y ago
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.

Qerub 9y ago

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.