Many Payment Method providers API like Braintree, Stripe, etc etc provide a callback system that allow the merchant to be notified with the result of transaction.
The main question is: How I can be safe from malevolent requests?
Suppose an attacker can reproduce our exposed callback REST API (obviously with HTTPS) this would lead in many fake successful transactions.
Is there any method to prevent this? I read about CRSF token on Stripe link, however it's unclear to me how it would be securely passed between my ecommerce site and provider API.
Stripe's callback system is called webhooks (https://stripe.com/docs/webhooks)
To prevent potential attacks, Stripe will send the callback content together with a signature. The signature is a (HAMC SHA256) hash of the callback content with timestamp and webhook secret. You could verify the signature (https://stripe.com/docs/webhooks/signatures) to ensure that the data is indeed sent from Stripe.
Related
I've been integrating Azure API Management with Paypal.
Here is the current flow
User goes to APIM portal and Signs In
Azure B2C flow is executed
On Auth Success the Delegation endpoint is executed to evaluate the APIM operation (SignIn, Subscribe, etc)
When the operation is Subscribe, redirect to the corresponding Paypal subscription link
Paypal flow is executed
Paypal return to the delegation endpoint configured in Paypals returnurl
So far so good, the issue I'm having is that the ony thing I have access to from paypal is the referer, which is like this
https://www.sandbox.paypal.com/webapps/billing/subscriptions?ba_token=[BA_TOKEN]&country.x=US&locale.x=en_US&mode=member&token=[TOKEN]
I'm lost on how I could use those tokens to identify which product the user subscribed to.
In step 4, store the subscription link or its ID before redirecting the user, as a pending checkout/order.
When they return, note any additional parameters in the return URL.
This should give you enough information to match the return event with the original subscription redirection and user.
For the best experience, change your flow to use no redirection at all.
See the modern "in-context" JS buttons solution here, which keeps your site loaded in the background: https://developer.paypal.com/docs/subscriptions/integrate/#4-create-a-subscription
(If you don't know what that means, click the PayPal button in this demo and note the window that opens; that's essentially the experience: https://developer.paypal.com/demo/checkout/#/pattern/client )
I'm working on creating a REST API and one feature is to allow users to register. The general flow is the following:
The user specifies his email and password using the client application (SPA application) and presses the submit button.
A request to the API is made. The API adds the user to the database, generates a verification token and sends an email to the user.
The user verifies his email and clicks a confirmation link.
The API marks the user account as verified.
My question is regarding the confirmation link.
Should the link point to the client SPA application? In this case, the client application will make a POST request to the API with the verification token and the user email.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Another approach would be for the link to go to an endpoint defined by the API. In this case a GET request will be made with the user email and verification token and the API will set the account as verified and inform the user that his account is now active.
I have read that this approach doesn't conform to the REST principles because a GET request should never change the state of a resource. In this case, the user resource will be modified.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Thanks!
Should the link point to the client SPA application?
If your 'Client SPA application' is the sole frontend for end-users, then yes: it should point there. Some people deploy a separate oauth2 / authentication server but that doesn't sound like it's the case here.
The client application will make a POST request to the API with the verification token and the user email.
The token should be enough. I'd avoid sending email addresses through urls.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Both seem like really valid designs. If you want the API to be completely unaware of the front-end and support a multitude of frontends, it would make sense to me that the client sends their own endpoints. There is a security concern though, you don't want arbitrary clients to register arbitrary urls.
If you're just building a single frontend, I don't see a problem with the API knowing the activation url. It also sounds like it would be easy to change if your requirements change later.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Ultimately it doesn't really matter that much. Neither approach sounds like you're really painting yourself into a corner. Either you have a standard endpoint that uses a javascript HTTP request to activate a user, or you have a separate endpoint that redirects a user after activation. Both will work.
I'm using Stripe API(REST) and I need to put a link in email where user can directly unsubscribe/delete subscription(https://stripe.com/docs/billing/subscriptions/canceling-pausing).
I need to know if it is possible to put the arguments and operation in a URL so that when user clicks it, Stripe api is called and subscription is cancelled.
thanks in advance.
The short answer is NO.
Cancelling subscriptions from Stripe API requires your Secret Key which you should NEVER expose in the front end and made public because user will have access to your stripe account in that case.
Saying that, what you could do is to expose an endpoint in your own web server, which you will need to
1) create a on time use token which you can look up your customer and related subscriptions; include the token in your URL send to the user
2) when user click the the url, verify the token (valid non expired) and find the customer and subscriptions
3) Call stripe API with your secret keys to cancel the subscription for the customer.
I am a long paypal API user and am trying to use the new(er) REST API for my app. I have been pleased with the quality of the docs and API over our existing integration with paypal masspay, but I fear I have misunderstood the use of the REST API.
I have done at least a dozen other OAuth2 integrations with a lot of different services, and every one of them sets up a connection and gives us (the 3rd party app owner) a token, which lets us act on their behalf.
When I discovered the "My Apps" and REST API of paypal, saw it generated a client_id/secret, naturally I assumed I could create an app, and integrate it into my software, so that my clients can 'add' the app (initiating an oauth connection), and then I have a token that I can use to create payouts on their behalf. What led to the confusion, in retrospect, is that I was able to obtain a token, and then make SOME REST API calls (specifically, the identity calls, which give me info about my clients paypal account), but even if I added the following oauth scopes:
https://api.paypal.com/v1/payments/.* https://uri.paypal.com/payments/payouts
I am getting permission denied whenever I try to initiate a payout, or use any API other than the identity calls.
So after further digging, I am coming to the conclusion that the REST API, and the whole 'apps' thing is simply for writing apps for your OWN account (except for identity), NOT for allowing my app to act on behalf of a 3rd party, as has been the case for every other oauth integration I have ever done.
Does this sound correct? Am I missing something that lets me identify what merchant I am acting on behalf of?
I'd really like to move off the masspay API as its very clunky. Please help!
I'm using JWT authentication on my REST endpoints, but once you make an account you can opt to purchase a subscription.
However, the purchase endpoint is a POST to /subscribe/new and if anyone gets the jwt from session storage, they can pretty much make CURL request to the endpoint and purchase a subscription.
Is this how it is supposed to work? How do I stop someone from just doing CURL to purchase a subscription? Obviously they need to supply additional information in the body like their payment details and stuff, but if they do that then it will go through provided they have the token.
So if a bad person gets that JWT somehow from the user's session storage, they can pretty much wreak havoc right?
You simply can't avoid that someone post a request to your endpoint. See https://security.stackexchange.com/questions/42586/ensure-web-service-only-accessed-by-authorized-applications
So assume it can happen and if it is a risk for you, be prepared:
do not authorize access to the service with this JWT
use an additional authentication factor for restricted operation:a password, an SMS, etc.
request the needed data and validate it before authorize access: for example the credit card number