#avery_error
tawdry vergeBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1294330598936154164
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
grave urchin
Hi 👋
Can you share an example request that is throwing an error? Unfortunately there isn't much I can do to help with automated card testing but I can at least take a look and offer some recommendations.
topaz wave
These are live payments
req_rAT1MVSJlsgC3z, req_2DhcOBVB0ao3NK, req_62HMvoCZCql45M, req_oItxmCo3kYptbB
It would be super helpful if you could tell me where these tokens are originating from
grave urchin
The tokens are being created from your android integration.
Here is an example request: https://dashboard.stripe.com/logs/req_u9ZUhM4OZJM1m2
That request creates the token that is being passed by your NodeJS code in this request: https://admin.corp.stripe.com/request-log/req_rAT1MVSJlsgC3z
The same thing in this request: https://dashboard.stripe.com/logs/req_QedSpgak60whxC
(except this one is using a React Native SDK but on an Android device)
topaz wave
Are they all coming from Android?
grave urchin
Android devices, but the second one I shared was using the React Native SDK
topaz wave
Do you know what source type they are? All card?
topaz wave
We don't get this much android traffic so it's very concerning
grave urchin
I would review your account logs looking at the v1/tokens endpoint
topaz wave
The linux portion of that is even more conerning
Yeah I am and it keeps getting spammed with declines
That's what is confusing this is way too high decline rate
grave urchin
Yeah you might want to roll your publishable key
You can keep the old one enabled for a set period of time while you swap out the new one in all your client applications
topaz wave
That is our server request so I don't think it's an issue with server
Someone must be emulating our app and trying to make payments which makes zero sense
grave urchin
Sorry I'm talking about this request; https://dashboard.stripe.com/logs/req_6VwQMIOgRoo0xH
which is coming from an Android integration
topaz wave
Yeah these are bot accounts
grave urchin
And it's being made with your publishable key
SO if you rolled your publishable key, with some delay to get all your valid client applications updated, you could stop these requests
topaz wave
But if they are still botting then we'll still get these
hmm let me look into how to prevent this type of attack
grave urchin
But if they are still botting then we'll still get these
No, not unless they downloaded a fresh copy of your client application
I think you are not understanding how the keys work.
They could be running the same code to automatically make these requests
topaz wave
I do understand how they work
grave urchin
but if you rolled your key, they would all fail at the very first layer of Stripe infra
topaz wave
But they can just download our app again with the new pk no?
grave urchin
You would not see declines because the tokens would not be created
But they can just download our app again with the new pk no?
That's the part that you would need to review. How are they getting your app
Do you have any additional security measures in place to prevent bad actors from acquirring your source code
topaz wave
The code is minified and they have to log in to call this request
Let me look into this more
grave urchin
they have to log in to call this request
I'm not sure what that means. If they have the PK they can actually use just about any method to make an HTTP request. We have enough metadata in the requests to know it was coming from our Android SDK though.
I agree that the payment_user_agent: "Dalvik/2.1.0 (Linux", value in the request is rather supsicious
topaz wave
They have to log into our app in order to add a card, so it seems they are bypassing our login
grave urchin
Oh, okay
So figuring out how to lock that down more securely + rolling the exposed key should stop them.
topaz wave
Alright I seemed to have locked them out
I still don't quite understand why I need to roll the pk. Can't they just scape my application to find that once I update it?
grave urchin
It increases the amount of work it will take to spoof requests. Sure they can always put in the effort to find it again if they really want to but generally the more friction you introduce the fewer criminals will put in the effort.
They are working a high volume, low margin enterprise so even slightly increasing the amount of work it takes to use your account credentails can make it not worth their time
grave urchin
Essentially yeah