#davidfox-card testing

1 messages ยท Page 1 of 1 (latest)

stark topaz
#

๐Ÿ‘‹ happy to help

woven rock
#

That would be fantastic @stark topaz ๐Ÿ™‚

stark topaz
#

using Captcha is only recommended if you feel that card testing is a potential attack on your site

#

usually it is

woven rock
#

Yes, I think it is. We were getting lots of failed payments come through. We removed the payment form from the site and the failed payments stopped

#

How do you recommend implementing captcha here @stark topaz? It would be really useful if you had example(s)

stark topaz
#

yes it would be a good idea to implement captcha

#

I'll have to dig into our docs to see whether we have an example somewhere

woven rock
#

@stark topaz I understand that implementing captcha would be a good idea, and it's something I'd like to do.

The issue I'm having is I don't know how I can securely integrate it when I am confirming the card payment on the front end.

Even if I confirm the captcha result using an API route, I'm still going to have to store the result on the front end, which will be easy for any hacker to circumnavigate (e.g. they could just change the front end state themselves to say that the captcha passed when it didn't).

I'm not sure you'll have anything in your docs, I just spoke with your live chat who said there were no docs. It's not really very helpful because I still don't know how to implement it.

Surely this is quite a common scenario for customers using Stripe Elements?

stark topaz
#

I'm looking into this

woven rock
#

Thank you ๐Ÿ™‚

stark topaz
#

when you say store the result on the front-end, there are multiple ways of doing that

#

if you're referring to localstorage or something like so then yes, it would be easy to circumnavigate and get around that

#

but if you're using a state management and saving this in the state, I don't think your malicious customers would be able to change that

#

I think that's your best option

#

disable the confirmation/submission of Payment Element until Captcha was passed/successful

woven rock
#

Yes, either local storage or state. I agree, it's not really going to work with Stripe Elements. What is the alternative?

stark topaz
#

no I meant that state would work with Stripe Elements

surreal flint
#

Taking over here

woven rock
#

Thanks @surreal flint, the issue with using state is I can go into my browser and spoof it.

If hypothetically we were calling the Google API and storing the result of the captcha in state, I could go into my browser and change the state to passed then process the card payment. It's too easy to circumnavigate

surreal flint
#

Why would you need to store it in state? Surely it's an async call you just await and then submit the form (assuming success)

#

I'm (we're) not familiar with third-party CAPTCHA APIs so how you integrate that really is your own call

woven rock
#

Regardless of how it's stored locally, I think it's still the same issue. If you await the response from Google on the front end and store it in a 'passed variable', then only run the stripe card process if passed is true, surely it's very easy for the attacker to spoof the response and set passed to true even when they've not actually passed the CAPTCHA

#

A POST request would be sent to Google at the following url https://www.google.com/recaptcha/api/siteverify

The response would look like this:
{
"success": true|false,
"challenge_ts": timestamp, // timestamp of the challenge load (ISO format yyyy-MM-dd'T'HH:mm:ssZZ)
"hostname": string, // the hostname of the site where the reCAPTCHA was solved
"error-codes": [...] // optional
}

But since this is all happening on the front end, how can we be sure that the process has been completed properly? Normally you'd do something like this on a server (or API route in the case of Nextjs), but stripe.confirmCardPayment is for use on the front end

surreal flint
#

Again, this is a detail of your integration that's not specific to Stripe

woven rock
#

You mentioned "Surely it's an async call you just await and then submit the form (assuming success)". My question is, how can we trust the integrity of the 'success' when it's all done on the front end

surreal flint
#

I'm not overly familiar with how people implement CAPTCHA in their checkout flows, but I'm sure there'll be a lot of material online

woven rock
#

How is this not specific to stripe? It doesn't matter what the CAPTCHA service is, you can take Google out and drop any other service in. The question is about Stripe Elements and how we can integrate any sort of CAPTCHA process with it, since CAPTCHA is mentioned in your docs (here: https://stripe.com/docs/card-testing#captcha).

I've searched online and I can't seem to find any info on integrating a CAPTCHA process with Elements

Learn about what this fraudulent activity is and how you can optimize your integration with Stripe to prevent it.

surreal flint
#

How is this not specific to stripe?
Because you're not integrating one of our APIs/products. You're asking how to use a third-party service and how to prevent malicious activity

#

This is integration specific, we've suggested ideas and that's all we can really do. We have no specific CAPTCHA guidance