I'm setting up a payment gateway on our site that we can post information to via php (so all information is hidden from prying eyes) which will post to authorize.net, post back to our gateway and post back to our current page. The purpose for this is to give us a streamlined method of processing payments and easier debugging.
I have an auth key that is required to be posted to our gateway for the transaction to be processed. Is it worth it for me to secure a list of approved URLs to accept posts from, or is that too easily manipulated?
Do you have any other ideas on what I should focus on in regards to securing my gateway?
update
This gateway has a login/key pair used for authorize.net that it submits to. I have a 64 digit md5 encoded key that I use for domain.com to communicate with gateway.domain.com which happens of course over SSL. I'm inquiring as to whether that key is enough. Given, anyone with that key could run a transaction, but why would they... it would only be giving us money.
A list of approved URLs will do very little to protect your gateway:
curl -H "Referrer: http://happy.example.com" -D "pay_to=evil#example.com&amount=$100,000" http://example.com/gateway.php
You should take a look at using something like OAuth, where each request contains a unique token that only an authorized actor could provide.
Also remember that POSTing data only provides the illusion of security. It's easy (nay, trivial) to see what data is posted.
Oh, and this should be a no-brainer, but make sure you're using SSL.
Related
I have a Cloudflare Worker that presents a registration form, accepts input from the user that is posted back to the Worker which then sends that on to an Node HTTP API elsewhere (DigitalOcean if that matters) that inserts the data into a MongoDB (though it could be any database). I control the code in both the CF-Worker and the API.
I am looking for the best way to secure this. I am currently figuring to include a pre-shared secret key in the API call request headers and I have locked down what this particular API can do with database access control. Is there an additional way for me to confirm that only the CF Webworker can call the API?
If this is obvious to some I apologize. I have always been of the mind that unless you are REALY good at security it is best to consult those who are.
You can research OAuth2.0 standard. That is authorization standard for third party clients. Here is link: https://oauth.net/2/
This solution is the most professional.There are other less secure ways to do it, but easier to implement. Password and username, x-api-key, etc..
It sounds to me that you can also block all IPs and allow only requests from that specific domain name (CF Worker)
I have an IPN for Paypal.
I have a simple NodeJS server using the express framework.
I have a simple post wrapper for the handler url of the PayPal IPN.
I have a simple check for IP address to check if the POST request came from PayPal.
My problem is that if someone spoofs the IP Address and sends POST Requests to the IPN Handler, they can effect my back-end system as the IPN handler has functions that are determined from the POST data.
How can I make this more secure?
Thanks.
Preventing IP spoofing isn't something you can do server side. What you could do potentially is implement mechanisms to asses whether or not an IP is valid and see where it potentially comes from. Afterwards you could limit the IP's themselves to whatever is acceptable for you solution.
The spoofing part is client-side, meaning that if the client uses a Proxy for example he could spoof the IP through that and you wouldn't be able to tell straight away.
Check out this short article for a bit of general idea (https://www.kaspersky.com/resource-center/threats/ip-spoofing)
IPN is a very old, very clunky service. You probably shouldn't be using it. There are invariably superior and more reliable ways to accomplish whatever it is you are trying to do with PayPal, including synchronous server-side capture or, only when necessary for certain asynchronous notifications, Webhooks
But if, for some strange reason, you insist on integrating such an old service as a payment dependency, its architecture has a built in verification step where you post the IPN message back to PayPal to have it verified. See https://developer.paypal.com/docs/api-basics/notifications/ipn/IPNIntro/#ipn-protocol-and-architecture
SagePay's form callback can be hacked by re-using the success URL that the user is directed to upon a successful transaction. This can create all sorts of problems with duplicate transactions, fake transactions etc.
You can check for a duplicate VPSTxId, but these can be generated anew by hacking around the crypt parameter of the callback URL.
The crypt parameter can also be manipulated to generate a different "Amount" field.
I have not tested what other field values can be changed by hacking the callback URL crypt parameter.
Is there any way (as per PayPal's IPN validation) of doing a double-check callback to SagePay to ensure that the transaction is new and unique?
Thanks for your post. In general we encourage clients to use Server integration where they can. We also constantly monitor transactions for suspicious behaviour and proactively contact our customers if we suspect any malicious activity.
We recommend customers make sure that they’re using the latest version of our integration protocol which is currently v3. Get the latest integration documents.
As Dan suggests you could use the Reporting and Admin API to validate that a transaction does indeed exist on the Sage Pay side but having an additional validation mechanism (like PayPal's IPN) is something we will actively explore.
If you'd like us to update you on this, then please get in contact with our customer services team at support#sagepay.com or 0845 111 44 55.
Sage Pay Support
You should always redirect a user from a success URL.
I personally use a fulfil page (success url), and a thank you page. On the fulfil page, you should obviously only ever process a transaction once (based on the transaction id), and you can store crypt sent with a transaction. The crypt will have to be valid and is only possible to encrypt if you have the encryption key.
So hacking would be extremely difficult unless you are being very security lax, and the hacker would have to know your encryption key to even begin trying to hack it.
Alternatively, you should use the server integration, so that the communications are server-server, not client-server. There is little difference between form and server.
10 immutable laws of security
http://technet.microsoft.com/library/cc722487.aspx
The situation is this:
A payment is made to one server, and on completion, it must notify another server securely. What I am trying to do is actually quite similar to a notify_url of a payment service. I.E. paypal receives a payment, and then notifies the origin through a long URL.
How does one verify the data being passed. Any useful libraries? Any links to get me started?
Thanks!
HMAC is a good way to ensure that the URL has not been generated by an unauthorized party or tampered with in any way. Here is a simple tutorial.
If the URL (or the content it returns) contains any sensitive information, then you'll also want to make sure that the recipient server is SSL enabled.
And for a further layer of security, you could hard-code the recipient server to reject any connections that aren't from the IP address(es) of your known sender(s).
What are some good suggestions or resources to look at to help me secure a single click URL based authentication?
Essentially, the situation is a third party system which accepts an HTTPS request, through the browser, where you supply authentication information (un, pw, authkey, etc...). The service then, upon authenticating the provided credentials, will allow or deny login access. The point being, that if someone clicks on the link, they're automatically granted access to this third party system.
Currently, there isn't a whole lot of security surrounding the whole process, (which isn't a big deal because the product isn't in production yet) and the third party is willing to make some modifications to secure this up a bit.
I've already determined I need to hash the information, and probably even submit it via a POST to prevent it from showing information in the browser history. But I'd like a little input on how you all would handle something like this.
[Edit: Requests are and will continue being sent via HTTPS. I also modified the HTTP previously used to be HTTPS]
Don't think about "secure this up a bit". It's either secure from the ground up, or it's got holes that will cost you dearly.
Look at HTTP Digest Authentication. It's simple, reliable and works well under most circumstances.
Look at the OWASP.org top-10 vulnerabilities. Be sure you understand and address each one.
You should probably use HTTPS to avoid the credentials being eavesdropped upon while in transit to the third party web server.
Protect yourself from using stale link to gain access to the application. Make the link be dependent on current time value