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

Jici · 2021-02-27T16:20:27.773Z

I cmpletely forget that for signature you need to compare the header content with the raw body.
I think, but I may be wrong that the process may look like this
A) Activate detect header data in endpoint
B) Create a request to the “events” endpoint" ( https://api.stripe.com/v1/events/[eventID]) Set this as a TEXT type, not json
C) In the endpoint you will need to use a plugin that let you decode the header. I think the best thing would be to create one that will process all the signature and comparison. Will have basically three fields: A) Webhook Endpoint Secret B) Body (from the endpoint created as TEXT) and C) Header (from the API request data). This plugin should return true if the signature is ok and false is not. I guess it would also be possible using an existing HMAC decoder plugin that already exist and just compare the result of this plugin with the Get Event Body from API Connector.

Not sure if this will work, but actually, this is something I think may work. If the event from webhook and the event from API are the same, there’s no reason that this will not work

sudsy · 2021-02-27T16:29:23.472Z

Jici:

I cmpletely forget that for signature you need to compare the header content with the raw body.

Exactly.

So you’re suggesting that a separate request be sent back to Stripe just to fetch what it has already delivered to the endpoint. I’m not sure if that would work either, but it would be interesting to try. (I’m not fond of the inefficiency of that approach though.)

Thanks for the suggestion.

EDIT

Now that I think about it, though, if the data is being pulled directly from Stripe via the API, it would seem to make signature verification pointless.

matt_moo · 2021-02-27T17:00:15.498Z

Hello,

ty for the discussion, my post was intended also to create interest in finding alternatives.

sudsy:

Now that I think about it, though, if the data is being pulled directly from Stripe via the API, it would seem to make signature verification pointless.

That’s correct, but that will reduce the benefits on using webhooks.
You use extra resources your app, and your api usage on stripe get higher(100 read/100 write *s is the current limit)

Just a remainder:
if you retrieve a invoice, that for stripe is not just 1 api call, but 1 + every invoice item in the invoice.

I think that API usage shold not be w8st on invoice or subscription, but is better usage of them for Card information, payment session, all those thing that is super important to have the information immediately and not have save in your DB.

Jici:

B) Create a request to the “events” endpoint" ( https://api.stripe.com/v1/events/[eventID]) Set this as a TEXT type, not json

maybe this could work, i didn’t check, but having a better support from bubble directly with event managed as bubble event that’s what we should have, to build proper integration with stripe.

Just to remember that current issue with stripe and bubble is also multi item in stripe invoice or subscription that as not readable in bubble as independent object, so that i can save not just the invoice in my invoice db table but also the invoice item in my invoice item table.

in the end a better stripe event (aka webhooks) in Bubble is not needed just for security and create an optimized app, reduce the load on our side and stripe side. But also for providing better usability of those data.

Using the metod proposed by @Jici that call stripe to have the object directly, and ipotises that the object was a invoice with 3 item.
It will cost you 4 call and 7 read operation on stripe.
Call:

Retrieve invoice (4 read operation: 1 invoice, 3 item)
Retrieve invoice item (1 operation * 3 times)

sudsy · 2021-02-27T17:07:17.921Z

matt_moo:

That’s correct, but that will reduce the benefits on using webhooks.

Yes, I would prefer proper sig verification when the endpoint is hit. I know exactly how I would build such a plug-in, so it’s a bit frustrating to not be able to access the delivered payload.

Jici · 2021-02-27T17:11:52.836Z

@matt_moo
What do you mean by invoice item? Do you mean invoice line? If yes, there’s no reason to do 4 calls. Invoice endpoint already give you data for Invoice line. No need to do a call for each line

My last post was only related to validate the signature. 1 API Call. If you want to store the Invoice data too… 2 API Call. Don’t forget that the Rate limit 100/100 are /seconds!

Jici · 2021-02-27T17:12:57.130Z

And I agree that it would be a good thing if Bubble can have an option for Raw payload (Giving you both: raw and parsed)

matt_moo · 2021-02-27T17:15:19.796Z

What you call line are item → Stripe API Reference - Invoice Items

And bubble is not able to read those object independently or as an array of object.

So if you want to save them on your db you need to do a call for every record in that array.

matt_moo · 2021-02-27T17:20:17.026Z

that’s why I mailed bubble directly, but they just replay to check on the forum.
But clearly we can’t find a properer way by our own.

And better stripe event integration will reduce a lot of time consuming endpoint development and provide better security.

Jici · 2021-02-27T17:22:19.889Z

You cna save them as an object in DB. If you set the call as DATA, you can save it like you save a Bubble Data DB. You just need to select this as a field. And if you want to create one thing in your own DB for that, you can use a Backend WF to process the payload (previously store in your DB) for each line. No need to call API again.

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