frisbee-rate-limit | Stripe Developers | Page 1

trail zealot Mar 23, 2022, 4:40 PM

#

Hi there! Sounds like you may be experiencing a card testing attack. Not much you can do. Can you provide an example request ID that I can take a look at?

rare stone Mar 23, 2022, 4:42 PM

#

req_bi9RG6nu9zpP5l

#

The attack started 2 days ago, and we've made some changes on our end to alleviate it

for example:

requiring a login user to create stripe checkout
disabling their account
block the customer using Radar Fraud Team

but i see from the logs that they are still continuing the attack.

#

The attack caused us to go over the stripe rate limit and we're worried that it will happen again

trail zealot Mar 23, 2022, 4:47 PM

#

Thanks for the info. Taking a look

#

Okay so yes, appears to be a card testing attack. The mitigations you have already put in place are good. You could also look at payment failure per PaymentIntent and after say 2 or 3 they cancel the Checkout Session so that the attacker can't use it and always has to do a new one. Additionally you may want to add a captcha per IP.

rare stone Mar 23, 2022, 5:03 PM

#

hrm... it sounds like i should do this in the webhook and listen to the event payment_intent.payment_failed ?
In that event, does it let us know how many times it has failed already?
Or do I need to keep track of that myself?

trail zealot Mar 23, 2022, 5:05 PM

#

That is one way to do it. The other would be to use Custom Radar rules from our Rules Reference: https://stripe.com/docs/radar/rules/reference

#

(Sorry for not clarifying... if you use the Webhooks route then you would track this yourself)

rare stone Mar 23, 2022, 5:16 PM

#

If we use the Radar rules to block them, does it still count against our rate limit?

strange shell Mar 23, 2022, 5:29 PM

#

HI 👋 I'm taking over for @trail zealot . Give me a minute to catch up

#

Unfortunately Radar is not designed to stop Card Testing. And, since Radar rules react to API requests, those requests would still trigger rate limits.

rare stone Mar 23, 2022, 5:32 PM

#

So it sounds like I would need to go through the webhook route right?

strange shell Mar 23, 2022, 5:37 PM

#

Yes using the webhook to cancel the Checkout Session should cut down on the card testing and API requests.

rare stone Mar 23, 2022, 5:40 PM

#

Another related question:
In stripe's dashboard, I see that the logs show me the request id of each attack. Is it possible to kill their checkout session from the dashboard using that request id

#

For example with req_1mIB38O4AvJZ2x, I don't see the checkout session id or the paymentintent id anywhere

strange shell Mar 23, 2022, 5:42 PM

#

I think that the checkout session ID is in the URL: cs_live_b1SALD0uIdtGqEclXxEwk0616bloHcOmgnDox2oqeQdBSrhcZmN19KA9Jl

rare stone Mar 23, 2022, 5:44 PM

#

Hrm... i see that it is suffixed with ellipsis (the 3 dots). Is it cut off?
it doesn't return anything when i search for it in the dashboard

#

oh Nevermind. looks like even with the legit and successful checkout session ID, they don't show up any search results

strange shell Mar 23, 2022, 5:46 PM

#

Yeah, if you use the API you can retrieve and/or expire the session by the ID:
https://stripe.com/docs/api/checkout/sessions/retrieve

#

https://stripe.com/docs/api/checkout/sessions/expire

rare stone Mar 23, 2022, 5:47 PM

#

I was trying to see if i could just kill the attacker's session using the dashboard because adding and testing the webhook would take a while

strange shell Mar 23, 2022, 5:48 PM

#

I don't know if that is a feature of the dashboard. The programmatic approach is likely to be more reliable and require less active maintenance on your part (after the code is written).

#frisbee-rate-limit