I have a server and a client application which runs in a web browser.
I know it is better to make client do the request directly to the payment processor (by what's called a payment page)
Having said that, I would like to know if it is considered OK in terms of security and PCI, to send the CC information to the server via encrypted HTTPS transportaion and the server will send the data to the payment processor without saving the CC information
I am using ruby on rails for the server side and a gem called ActiveMerchant with another gateway support gem and I could find a way to do the payment from the client directly to the payment processor. It seems that request should pass through the my server anyway.
This is most likely not okay, since the credit card data is still unencrypted in transit (from SSL termination to your rails server) and might show up in server logs (obviously unencrypted) as well.
The payment provider we use, offers CSE (client-side encryption), which encrypts raw credit card data on the client such that it never travels as raw/readable data through our server. The encryption is asymetric and the encryption key is only available to the payment gateway making it impossible for our backend servers to ever read that data.
Related
Is there any added value in encrypted data we send in http request and response between client and server if we already have SSL / TLS ?
I get SSL/TLS already encrypts traffic across the transport layer for SSL/TLS connections but if we wanted to prevent browser users from reading request and response data, would encrypting it before it is sent add any value in preventing users being able to read it?
For instance, I could go to Network -> XHR requests -> and see what data is being transferred between client and server.
... but if we wanted to prevent browser users from reading request and response data, ...
It looks like you are trying to prevent the simple reverse engineering possible with using the developer console and looking at the requests and responses. While encrypting/decrypting the data in Javascript would make this simple reverse engineering harder it will not prevent reverse engineering in general: ultimately the browser needs to have access to the information in plain so some reverse engineer could tap into the relevant parts of your Javascript based crypto to get access to the data before encryption and after decryption.
In general: if the security of your applications requires protecting against the user of the application itself, then the security design is likely wrong.
I'm making app with VS 2017 and Xamarin. I plan to send username and password (in request body) to my server with httpClient (Android), PostAsync().
I have seen examples like the answer at
Send HTTP Post request in Xamarin Forms C# and just wonder if there is a way to check that the data beeing sent is really encrypted.
I know from https://blog.xamarin.com/securing-web-requests-with-tls-1-2/ that the httpClient would automatically encrypt messages.
Greetings
If you connect to your server using SSL the data you send will be encrypted. This can be achieved by simply using the https:// prefix when connecting to your server as opposed to the regular http prefix.
As you said that you are using SSL on your server I shall not go into the ins and outs of implementing it as it is very different on every platform. For anyone reading this in the future a great starting point is using LetsEncrypt if you're on a budget as it is free (although you do have to refresh your certificate every so often).
To verify that the data is encrypted you can use a program called Wireshark whilst debugging in an Android Emulator. The instructions are pretty clear within wireshark but on sending the request from your android phone select the domain/ip from the wireshark panel and view the information from that request. If you are using SSL right the data should be encrypted.
I am using Phonegap to build an app which has a form with credit card info which data get submitted to my server. The server has SSL on top of it, From there using the payment gateway API I generate a token for this credit card in order to process the payment.
Is it safe to directly post to the server since i use a mobile app therefore a potential attacker could not interact with the form itself?
I could post the data directly to the payment gateway to retrieve that token but I would like the server solution since I can handle any errors/exception better.
What is your opinion??
If you post card data to your server then you, it, its network and hosting environment must all be PCI complaint which is a major undertaking and involves significantly more than simply using SSL: Q: Am I PCI compliant if I have an SSL certificate?
I could post the data directly to the payment gateway
Yes. Do this, its a no brainer.
i really don't like Hybrid techs for mobile development. But, You need to create some validations like SSH pinning. Because an attacker can perform a mitm and maybe they can get some informations. Another problem is that using hybrid techs is more easy to perform a reverse engineering and maybe an attacker can get important data too.
I am familiar with the "SSL handshake" and how it works between client and server, I am just trying to comprehend what happens after its all over. Say you go through the process of buying something through an HTTPS website. After it is all said and done that information has to be decrypted right? Where does your data go? Is your data decrypted and stored in a database of the company where you purchased your product?
SSL only encrypts the data as it is in transit from the client to the server, or vice-versa. If you use your web browser to connect to a web server through SSL, and send your credit card information to the web server through SSL, your credit card information is encrypted as it is sent through the internet from your web browser to the web server. But, once it arrives at the web server, it is decrypted, then there is no telling what could happen to it. Hopefully the company that operates the server handles your credit card information securely. But, we've all seen all of the recent cases of sites that have been hacked and millions of credit card numbers have been stolen.
I was discussing development of an API with a colleague, and the following proposal has made me wonder about the securability of it.
Scenario:
There is a web application that is running on server A that (in addition to other functions) allows the admin user to specify arbitrary URLs, and security for the users within their account related to each URL. So basically:
URL:"/foo/bar", UserID:1234, AllowedToView:true
The admin user then has their own web application running on their own, separate server B. And they want to check if their end users that have logged in on that server B application have access to a particular URL on that server B application by checking against the API on server A.
This check could come in 2 forms:
A server-side HTTP call (from server B to server A) that happens within the context of a user requesting a url from server B, so this would look like:
User requests "/foo/bar" with their client from server B
During the processing of that request on server B, it makes an HTTP call to server A to check if that user has access to the requested URL
With the response from server A, server B can then either allow the user to access or redirect, send 403 access denied, etc.
An AJAX request from the end user's client directly to server A and utilizing the response with JavaScript. An issue of cross-domain scripting could be problematic here.
One challenge that comes to mind immediately is that there would have to be a way for the admin user to directly associate the end user that is accessing their web app on server B with the UserID that is associated with that user in the web app on server A. But let's assume that has been solved elegantly somehow :-D.
My question related more to the inherent (in)security related to a scenario like this. If the requests that are being made to server A (in both 1 and 2 above) are made with https, then can the integrity of the responses be counted on?
HTTPS makes sure the message can't be read or tampered with any relaying parties (proxies, etc.) but it doesn't guarantee the source of the data is trusted. If another service can determine the other URL and wire format they could spoof a request to it. This is generally where something like request signing comes into play using a shared-secret signing mechanism. Twilio's API uses this method to prove to you that they're actually calling your servers. HTTP Signatures is a proposal for a standardized way of doing this.
You can't rely on client side validation if you really want to secure your server B. That is, your second scenario - calling server A from the client side to see if it can access resources - is not a secure method. You need to count on the client to behave nicely, which of course leaves you open to attacks.
You first scenario - server to server call is a secure and preferred method. You will still need to secure your call using signing or just passing the shared secret itself to validate the origin of the call (using HTTPS).
That said, there are ways to secure a flow that goes through the client, but it will usually involve signing the data on the server since you can't have your client sign it (you can't place your secret in the client).