Stripe Webhook in Bubble - big vulnerability to all apps that use them

Jici · 2021-02-27T17:28:14.526Z

For security, the “Signature” security purpose is not a really big thing. I mean that basically, the only thing that is important, is the endpoint Secret key. For the rest, it’s just more complex step for no reason. I think, but may be wrong, that if you are just able to decode the header with the secret key, you can consider this validate even if you don’t compare both payload. Why? Because I guess that if you are an hacker, and think that the server will validate signature, you will send also an header that will follow Stripe payload. So basically: the timestamp will be fine, The body will be the same. The only thing that is different is, the Secret key. If you can’t decode the header, this mean that this doesn’t come from Stripe but someone try to hack your endpoint. If your secret key get hacked/stolen, this mean that the signature verification will say it’s valid and you get hacked even if you use the signature validation process.

matt_moo · 2021-02-28T00:46:07.475Z

Jici:

endpoint Secret key

You should never save bubble root API key on external services, and especially if is not encrypted as for webhooks url in stripe

Jici:

decode the header

Is not decoding, the stripe signature is a result of the entire call content combine with the secret key generated by stripe, similar to what you use on file with md5 signature to check integrity.
Just 1 bit of information will invalidate the signature and the event call (aka webhooks) should not be processed.

You can’t do a check on just the header.
And hack a SHA256 encoded signature is almost unhackable, you can search for 20 digit pass on SHA256 on google.
There is a reason behind the common standard in development and using cors + signature verification on webhooks is one of them, is super efficient to check the signature, is fast to generate the signature and is secure, no sorry super secure.

Using a standard API key is significantly less secure then use a signature, and you can’t compare what your propose as work around, in performance and efficiency and security with a simple web-hooks setup.

I know that bubble is a no-code platform, but if bubble team will provide us with the correct tools we can develop plugin that will make the app more secure and more optimized to process stripe event.

small information, we actually saturate the 100 sec request in read, for our main software some hour every 2 or 3 weeks, and we are a medium company, so is not something special what we ask, is just the basic on all platform.

Jici · 2021-02-28T01:15:37.447Z

@matt_moo
According from what I read from your previous post, there’s place to improvement in your process. If you are doing 4 calls for something that should take 1…

I’m not sure why you say ave Bubble root API when I’ve never mention this. I’m talking about the Secret key from Stripe for each webhooks endpoint. This is the key to encode/decode the signature. And sorry, I should ahve said that you need to encode and compare signature and not decode. My bad

Jici · 2021-02-28T01:19:04.691Z

I forget that, before Stripe introduce the signature, the real way to validate the data was to… call the API Back (You get the payload, but instead of working with it, you call the API Endpoint to get data from their API… this is a secure option too you can always do :P) But yes, This take one more call.

Jici · 2021-02-28T02:43:28.336Z

I’ve done some test with the “API connector” Get event endpoint. It should work but you will need to edit the received text for the part “pending_webhooks” with the data received from the Backend WF. This seem to be the only value that can change between the webhooks and the event call.
So basically, the process should be: Receive the payload (header activated), create a plugin that will have 4 fields: A) Signature. This will be the stripe-signature header. B) Event payload. this will use the API Connector Get Event (need to be set as TEXT type). C) Webhook secret key. D) pending webhooks. This will be data request pending webhooks.
Plugin will (in server side action): A) split header to get each part. Need to have timestamp from it and signature. B) Find and replace the value after “pending_webhooks”: to replace the number there by the correct one from the request data. C) Create the HMAC-SHA 256 signature using timestamp.jsonbody with the key. D) Compare the header signature with the one created. E) Return true or false according to the result.

I’ve test each part manually and can confirm this is possible. But it’s not easy and I’m not sure if this will work everytime. (Tested with 3 webhooks events).

But I really believe we should continue to ask bubble to have an option in both API Backend and API connector, like we can for headers, to have an checkbox to activate if we want to store the raw payload. It will make thing a lot easier and probably open a lot of possibilities around that features.

marty.lindsay · 2021-03-08T18:17:11.167Z

hi @sudsy . I agree with your plan. could you please show your syntax for the verification of ip. My OnlyWhen clause in my workflow isn’t valid:

All Stripe IP Addresses contains Request Data's headers x-forwarded-for

My Option set is All Stripe IP Addresses
I’ve enabled the ‘Included headers in the detected data’ checkbox & reinitialised.
The Detected data did in fact contain one of the specified ip addresses in that header value.

it’s a bubble issue of " Only when should be yes/no but right now it is empty"

sudsy · 2021-03-08T18:54:57.456Z

Sure thing, Marty…

stripe-webhook-config1412×1292 86.7 KB

I used the cf-connecting-ip header to get the originating IP, since the Cloudflare docs say it’s authoritative.

To create the endpoint name, I used this password generator (set to 32 characters) but disabled the punctuation option to ensure only valid URL characters.

And here’s the regex to extract the timestamp from the signature (for ease of copy / paste)…

(?<=t=)[^,]+

-Steve

marty.lindsay · 2021-03-08T18:58:12.897Z

awesome, thanks @sudsy . I should have known nocode would eventually have me writing regex again.
…Marty

sudsy · 2021-03-08T19:13:32.805Z

marty.lindsay:

I should have known nocode would eventually have me writing regex again.

Yeah, it’s one of the geeky things I allow to “pollute” my no-code logic. It comes in handy now and then. (I hate mixing JS into the editor environment though. Eeeewww! That’s what plugins are for!)

-Steve

marty.lindsay · 2021-03-09T07:10:40.668Z

@sudsy I must have set up my options weirdly, still getting bubble red error for my only-when. any chance of a screenshot of your options ?

sudsy · 2021-03-09T12:24:14.088Z

Can you share a screenshot? I’m not quite sure which options you’re referring to.

-Steve

marty.lindsay · 2021-03-09T19:25:49.602Z

cancel that, I finally got it sorted. Turns out there are a lot of ways that Option sets can be set up:
For anyone following along, the working config for me was:
Data | Option sets
New option set = IP security Checks
Attribute = Webhook IPs [ which is a list]
Options = Stripe

then click Modify attributes next to the ‘Stripe’ option you just set up, and add each of the IP address to that list ,from the stripe website here Domains and IP addresses | Stripe Documentation

bubble now seems happy with the syntax

sudsy · 2021-03-09T20:46:12.519Z

Oh, option SET. Yes, there is more than one way to set those up. Glad you got it sorted.

fabrice.latour04 · 2021-03-10T20:53:41.609Z

Hi @sudsy,

First of all thanks for your answers, they helped in finding a temporary solution to this endpoint accessibility problem.

I was digging a little deeper as I would like to implement a more robust solution and was wondering if you could help. I was thinking of following Stripes manual solution by comparing the signatures in the Stripe header against the result from a server side script (computing a HMAC with the SHA256 hash from the signed_payload [signed_payload= “timestamp” + “.” + “requestbody”] and the given Stripe Signing secret key).

Thanks a bunch

sudsy · 2021-03-10T23:12:33.457Z

Hi Fabrice,

What is “Server script”? I’m not familiar with what’s depicted in that screenshot.

Regardless, I can assure you it’s not going to work for a number of reasons - not the least of which is that Request Data’s body object is simply a text field that’s used to identify the type of Stripe object. In this case, it will simply read “event”.

That issue aside, I just don’t see how you’re going to get a reference to the raw payload in that context.

-Steve

fabrice.latour04 · 2021-03-10T23:28:59.134Z

Hi Steve,

I’ve encountered that exact problem today . I’m building a plugin script that will unflatten the received endpoint Request Data. That way I can then isolate the body object to concatenate with the timestamp. I’ll let you know if this approach works.

Cheers,
Fabrice

sudsy · 2021-03-29T08:34:02.721Z

matt_moo:

As one of the feature, bubble offer a Swagger file with all the endpoint and the relative object publicly on the internet.

FWIW, access to that endpoint can be disabled…

disable-bubble-swagger1434×398 44.6 KB

nocodeventure · 2021-04-04T14:45:33.105Z

Inside the endpoint api, have your first call lookup the actual payment in Stripe with the ID returned by the webhook.

Terminate the workflows if payment hasn’t come through.

I can’t see how that would not protect you from fake calls.

sudsy · 2021-04-04T18:00:06.632Z

nocodeventure:

I can’t see how that would not protect you from fake calls.

Assuming you’re replying to my post pointing out that the swagger endpoint can be disabled, I was not in any way suggesting that it would protect from fake calls. I was simply responding to just one of the concerns raised by the OP.

If you haven’t already, you might benefit from reading the entire thread - in particular, the post where I outline the my personal strategy for reducing the risk of fake calls. (And here’s a screenshot to go with it.)

nocodeventure:

Inside the endpoint api, have your first call lookup the actual payment in Stripe with the ID returned by the webhook.

That was already mentioned in this thread, and it’s not the approach I would take (for reasons others have already pointed out in this thread).

nocodeventure:

I can’t see how that would not protect you from fake calls.

It doesn’t. It can, however, add a bit of obscurity as part of a multi-faceted approach to reducing the risk of malicious calls. Even with that setting enabled, though, I feel comfortable with the steps I’ve taken for my sites.

I have no intention of adding extraneous authenticated calls back to Stripe in the context of a webhook.

system · 2021-04-13T16:43:24.989Z

This topic was automatically closed after 70 days. New replies are no longer allowed.