I am building out a registration system using PayPal Hosted Pages. From what I understand I can use the Silent POST feature to let my application know when a successful transaction has occurred on the hosted checkout page. I worry that it will be possible to spoof this POST request and manipulate my application into thinking a transaction was successful.
Example:
When a user checks out they are redirected to a URL like
https://payflowlink.paypal.com/?MODE=TEST&SECURETOKENID=XXX&SECURETOKEN=YYY
They can copy XXX and YYY and use an application like cURL to send a POST request to my application endpoint, thus tricking into thinking there was a successful transaction.
Is there a preferred method of securely handling silent POST requests to prevent this scenario? Is there a better method altogether of notifying my application of a successful transaction?
You can use a userid/and matching secure key as well as a date stamp, that way, only a random generated secure key, and a user id can be used, for a given time frame (usually couple minutes)...
Related
I am new to Stripe and payments in general. I've found few articles on the internet with the examples and guidelines eg. this one. As i noticed the algorithm for creating the payment looks like this:
Client app fetches the publishable Stripe key from the server
Server application creates the checkout session, client app fetches the checkout session id using retrieved publishable key
Client app redirects to checkout
User finishes the payment and being redirect back to client app
Please correct me if i'm wrong. In general i don't understand one thing - how the server application knows that the payment is completed successfully or not? Should i redirect the flow from stripe checkout to backend first, process the result and the from the backend call the frontend again? Or should i somehow use the checkout session to check has it been completed? Shall i use some kind of cron then to process pending checkout sessions? Thanks in advance for any help. Regards
Basically, what you lay out is viable. You can check the Session status when the client is directed back to your server, but you will want to check this status at least one other way, either via a webhook or the cron job you mention.
Should i redirect the flow from stripe checkout to backend first, process the result and the from the backend call the frontend again?
This is possible. Stripe allows you to add the {CHECKOUT_SESSION_ID} template parameter to your Checkout's success URL, when the user is redirected after their checkout, that template will be replaced with the actual Checkout Session ID which you can use to retrieve the Session and its status.
That being said, it is possible for a Customer to make a payment but have their connection cut out before navigating back to your page. So, if you rely on that redirect the customer will be charged but you will never know to fulfill their order. That leads to unhappy customers so Stripe typically recommends setting up a webhook endpoint on your server[2] so that they can send you a checkout.session.completed event to notify you that the customer has finished their Checkout Session. That way, even if a customer never gets to your success page, you will know to fulfill their order.
[1] https://stripe.com/docs/payments/checkout/custom-success-page#modify-success-url
[2] https://stripe.com/docs/payments/checkout/fulfill-orders
Noob here working on first backend project.
What I’m trying to do...
Collect member data via my form (name, email)
User clicks paypal button to pay for membership
When payment approved by paypal, send post request with form data to my members endpoint to add new member
I now realize if I use postman to post to my members endpoint it works. So a malicious user could post data to my members endpoint regardless of paypals payment approval.
My understanding so far is that if my server allows CORS and I don’t password verify the user, anyone can post to that endpoint.
Is it possible to allow post requests only after payment approval without the use of a password?
I’m thinking of online stores that let you checkout without a password. How do they post the collected form data to their db without jeopardizing their post route?
Hope this wasn’t too vague. Pointers would be greatly appreciated!
I’m using node/express, but since it’s a general question I assume it doesn’t really matter..
These answers helped but still didn’t get me there.
Protecting post routes NodeJS
Can I only accept traffic from certain requesting domains with Expressjs?
So post / get request in general are functions of the browser and or server, I can create a simple html form and post to any URL I want to.. Now the question is, will it accept it or not.
When communicating between servers and web-services unless open to the public will use token based authentication to validate the request. So in terms of paypal, the typical flow would be.
(note, very oversimplification below and is just a sample of one such pattern)
User clicks paypal button from your site ( this will contain some type of paypal ID of sorts )
User is directed to paypal and after completing the transaction paypal redirects users back to your server with a token
your server reads the token ( sends API call to paypal with token to verify its valid, if success then process the post )
You can't prevent a user from posting data to a URL, however you can tell the server what to do if they do. So protecting your route from unauthorized post can be handled by sessions, tokens etc. For example, if you have a route on your server, lets call it user profile. This route first executes a check for the session, if its there keep processing, if its not, redirect the user.. Its really no different for callbacks / token auth.
Essentially, you will need to handle what the server does in your code because anyone can post to the endpoint.
To your other question about how companies handle guest checkouts, this can be done a few ways but one way is to create your own token, this token would be an encrypted string that may contain a cart ID, time etc.
When a user clicks 'checkout' the token is generated and passed to the server via a get or post request. From there your server decodes the token and if everything is correct processes the order otherwise it kicks it back.
Again, you see a lot of token based stuff here going on and that because there is an X factor in all of this.. the user.. We know who the server is but the user can be from anywhere and the user isn't a server so we need some way to maintain state between servers, hence tokens, encryption, JWT etc
I have created login and signup end-points on node-js, using react-js created necessary form and field for login and signup and on submit of form, posting the data to the server and getting a proper response. And under network section inside the browser, users can able to see the endpoint and the data ( username and password ) provided by the user.
Is there any possibility to hide the request and the data from the users. In the same way, I want to hide a few API requests from the client aprt from login and signup. Like profile update, organization details and profile create/update/delete, permission create/update/delete
FYI kindly access the link provided below :
https://drive.google.com/open?id=1bbrsOQlE4159CMm2P0ktzNf6SfCd3h0F
Hiding requests under network tab is not advisable. Instead you can secure your request data using some sort of encryption library like bcrypt. with the help of libraries like this you can encrypt your passowrd before sending it to the server, that way you wont be exposing sensitive data to other people. And on server side you can decrypt the data again using the same library.
This should not be possible as far as I'm aware. Most of the dev tools built into chrome are not able to be manipulated by the browser. This would be to ensure a level of integrity between the user and the website. If you could hide network requests it would be catastrophic, allowing a website to send anything in the background without you knowing.
Facebook also sends your data through to the server in plaintext form.
Pausible Gif
Because of this functionality VPNs exist to encrypt the payload when going to the server. This is the data/network request that people intercept on public wifi's to gain your information (A brief explanation, research more if you're interested)
In my testing, I used a web proxy to get thru the firewall here so I could send envelopes. Now I will no longer be using the proxy. Do I need to log in for each web request ( like getting the templates, creating an envelope, etc )? The way we will use docusign is like this: a client consultant will see 3 documents that need to be sent to user X. So they will create an envelope with the 3 documents and send it out. They only need to connect to Docusign for a few rest calls and then they're done. The client consultants will connect to Docusign a few times a day, maybe no times a day if there are no documents to send. I'm assuming that I should go out and see if I can connect to Docusign without a problem before attempting to send out an envelope. What workflow are other people using in similar situations? Thanks for any advice.
I think a short answer here is that every API call you make requires a form of authentication provided, whether it is username/password or an oauth token passed in the appropriate x-header in your API request. I doubt your proxy was adding this on your behalf, so IMO I do not see what you will be gaining/losing by removing the proxy.
I am looking at the Moneris Payment Processing and their Direct Post method. For the life of me, I can't figure out how the security on it works.
As best as I can tell it does this:
Web User comes to my site. They fill out their credit card information (https).
I show them a summary in a form. When they hit submit they go to Moneris (POST) - including my ID, credit card info, and a custom Transaction ID.
Moneris processes the transaction and sends them back to my site (as a POST)
If they arrive on failed.php or whatever URL you specify, the transaction failed. Else:
If they arrive on gotyourmoney.php then the transaction seemingly worked. Time to validate. (included in POST vars is a Unique ID for the transaction, date/time stamps, response_code (got money, didn't get money) and a few other miscellaneous items.
I redirect the user back to the moneris site with another POST. I include my ID again and the Unique ID returned in step 5 to verify the transaction.
User is redirected back to gotyourmoney_verified.php as a POST again with the unique ID, Transaction ID, and response_code.
What I can't figure out is this:
No where does there seem to be any information that I can validate that the web user can't just make up. Even though it is an https connection I'm trusting the user to pass all information. They could immediately go to the gotyourmoney.php page and never even go to the moneris payment gateway. They can just make up the ID's. When I send them back to moneris for the transaction verification, again they could just post a made-up response to my site.
What am I missing?
The Transaction Verification feature of DirectPost can be used to prevent spoofing.
Here's how it works
A customer enters their credit card information on your site and the information is sent to Moneris for processing
Moneris processes the transaction and sends the transaction result to your site
If transaction verification is enabled then there will be a special field in the transaction result called a "transaction key"
Then to verify that the transaction wasn't spoofed, your site would send the transaction key in a transaction verification request to Moneris
Moneris would then verify the transaction using the transaction key and respond with a result that lets you know if the transaction was spoofed
The Integration Guide for DirectPost has all the details on how to implement the Transaction Verification feature and can be download at http://developer.moneris.com (free registration required).
In addition to Transaction Verification you can also setup a referrer URL. If a referrer URL is setup then Moneris will verify if the transaction is coming from an allowed URL. It's possible to circumvent the referrer URL feature but having a referrer URL enabled is still useful as part of a defense in depth strategy because it makes it that much harder to spoof a transaction.
Indeed since all of those things go through the client, they can easily be spoofed. And the Moneris documentation doesn't tell you this. You need some sort of server-to-server step to be sure that everything is in order.
I would suggest doing a preauthorization using the hosted pay page and then doing a capture with the PHP API. Since you're doing the capture server-to-server, any attempt to spoof by the client will just result in a failed capture.