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
Related
I've looked at various approaches to this but I'm yet to find one that is perfect for my set up.
I have a UI that calls the api to present data to a user - the UI doesn't require someone to login and i don't want to authenticate every user. What i'm trying to do is simply protect the api because with the url to the api, anyone will be able to access the data.
In my mind, i can create a password/ apikey of some sort and store that as an environment variable that is sent from the UI to the API whenever a request is made. On the API, that apikey/password is validated before allowing access to the api.
Does this sound wise? Would you suggest something else? Have i missed anything. All thoughts are welcome.
The solution sounds good to me. You can do something like this:
back-end: create a new REST endpoint (something like /api/get-token) in your Node.JS application which generates a token (or ID), saves it locally (maybe into a DBMS) and returns it as response. Then, in every endpoint you need to protect, you extract the token from the request and, before sending any "private" data, you check if the supplied token is valid, or not.
front-end: as soon as your application is loaded, you send a request to the newly created REST endpoint and store the given token locally (localStorage should be fine). Then, every time the UI needs to access "private" data, you simply supply the claim within the request.
The implementation should be pretty straight forward.
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)
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)...
I want to retrieve a list of recent photos with a given tag to display on a website in a very simple gallery.
For that, the doc says I need an access token. However, it seems that the only way to authenticate against Instagram is through OAuth; which involves sending the user to instagram and allowing my application access to their basic data. However, I don't want my users to do anything; I'd like my application to authenticate against Instagram for me and then retrieve the data I want.
Sounds simple, but all online documentation seems to end up in "Redirect your user to...". And I find no sensible ways to do this programatically; it's all about sending users away, letting them authenticate, and then receiving the access token afterwards. I could of course scrape the HTML, parse the forms (for example, the unique-per-session csrfmiddlewaretoken field which needs to be posted along with login requests etc) and let my server side application pretend to be my own user and login/authorize the app, but that doesn't seem like the way to go.
I could also just authenticate manually in the browser, pick up the auth token and paste into my application; but as the doc says: "do not assume your access_token is valid forever." - so I'd like this to be fully automated.
If I try to create a WebClient and POST to https://www.instagram.com/oauth/authorize/?client_id={clientId}&redirect_uri={redirectUri}&response_type=code&scope=basic it just returns a 403 Forbidden which is of no use. (For what it's worth, I'm using C# and have found instasharp, but this problem is not tied to any given platform...)
Am I completely overlooking something, or am I right that server side authentication against Instagram has become really complicated? Most other social media platform API's I've touched lets me get some form of authentication token just by posting a combination of the application id and secret.
I'm wondering what's the best way of accepting payments from credit cards that require 3-D Secure verification. Currently the checkout flow is like this:
Customer submits payment
Payment gateway returns an error stating that the card requires 3-D secure code processing. Returns the ACS URL in the response
I redirect user to the issuing bank's verification site and I pass a callback URL for the ACS to redirect after completion of verification
Customer enters verification code and ACS redirects to the callback URL with an authorization token indicating successful verification
To complete the process, I have to resubmit the original request with the authorization token to the payment gateway
My problem is in the final step. As I need to resubmit the original request (which contains the credit card information of the customer), I need to store it somewhere temporarily so I can retrieve it when the callback URL is called. Is there an alternative to this?
I'm thinking of trying an iframe solution: The original form is never closed and I display the verification process in an iframe. When the process completes, i.e. the callback url is called, I hide the iframe and update the original form with the needed values and resubmit. Has anyone tried this technique before?
As you might already noticed in article you linked, presenting bank's page in iframe is a preferred option. Although if you read in further, it presents other security features, specifically in regard to phishing protection. Because your client won't know to whom is he really sending his password.
But going back to your proposition, if you present it in iframe or popup window, you would be able to store the original form on your base page and then resubmit it with received authentication token. It's a very good idea because you would not need to do any PCI compliance stuff. So not only it's easier for you it is recommended :).
With Sage Pay (and I would assume other payment providers) you don't need to pass the full order information again in the last step, just the response code from the 3D Secure form and a unique transaction reference. Storing the card details is therefore not necessary.
For me the process is:
Card details etc. and unique transaction reference submitted to payment gateway.
Payment gateway responds with 3D secure details (ACSURL and reference codes).
Redirect user to 3D Secure form (passing ref codes and callback URL) where they enter their details.
Verification code passed back to callback URL.
Server must send the verification code and same transaction reference from step 1 to the payment gateway.
Payment gateway responds with success/failure information.
I've done some recent work with 3d secure. From my personal experience:
I pass the credit card information with a forward url to the banks
3d secure url.
The user is redirected to the 3d secure url and prompted to type in his password.
When he clicks continue, the user is passed to the forward url with the authorization token -- the credit card information gets passed along as well.