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

[Jici]

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]

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]

Sure thing, Marty…

 
 
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]

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

[sudsy]

@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]

@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]

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

-Steve

[marty.lindsay]

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]

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

[fabrice.latour04]

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]

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]

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]

@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…

[nocodeventure]

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]

@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.