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.
Related
Note: I am working on this as a learning exercise and not for using on an actual website.
I am trying to learn additional ways I could explicitly or statisticly identify a user so I could look at having a sort of "confidence scale" on how securer a users session is. So I could ask the user to re-verify their email if it looks like the password or authtoken has been leaked.
If a client is using a securer https connection then I believe that connection would be encripted in a way that is unique for that connection, and I'm interested in testing and trying to understand better how that information could be gathered and how it could be used.
So, Is there a way to collect the information exchanged during the server clients TLS handshake process on the web server?
I've been testing using Node.js at the moment, but would be happy to try a different langauge or software just to test this out.
Does anyone know if the client details would only be unique for the connection, or if they should be unquie for the browser or device or network interface? (For example if a mobile device goes from wifi to mobile data and the IP address changes Does the HTTPS handshake happen again wit the same or different values?)
And does anyone know if doing something like having multiple certificate for the domain and serving different certificate to differnt users would change the clients default responces on reconnections?
I would assume that the client could probably be identified by loading unique sub domains with unique certificates, and measuring timings to see what certificates in the certificate chain had been cached, and would like to test this, but also not sure if there would be a simpler or easier way?
I have mobile app which heavily depends on apis response, I was using charles proxy and fiddler to see the api calls made by my app and I have noticed for one of get api call I am able to see full url with all request parameters(which is fine) and request headers(which include secure keys).
So using those info anyone can execute that api outside of mobile app. my app has millions of user and if someone run script to increase traffic it also increase load on server. so is there any way I can secure or hide those keys ?
I am able to think only one way of doing it is
encryption on both app and api side
is there any better way of doing it ?
You can implement certificate or public-key pinning in your app (for the leaf or the root-CA-certificate). This makes it harder for an attacker to use a proxy and intercept HTTPS traffic. However with XPosed and SSL-Unpinning module this will still work.
Also keep in mind that APK files can be decompiled easily, therefore you don't have to attack the network traffic.
Therefore the next step is to harden your app to make it resistent against manipulation via XPosed or Frida. Note that good harding frameworks cost a lot of money. Usually the protection offered is raising with the cost.
See also this related question.
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.
I have a small device that contains a client program which communicates with a server over the internet. Pretty standard stuff.
I have a requirement that the server be able to authenticate messages coming from the device, meaning that all communications from the device be from the authentic client and not from some impostor. It's assumed that an attacker can reverse engineer the client and also load his own programs onto the device.
I'm questioning whether this is even possible. I could certainly load a client certificate into the client, but an attacker could get to this and use it himself. The cost of the device must remain low, so no fancy hardware tricks. Any ideas on how I could do this?
Depending on the device, and what kind of abuse you are talking about, you could use a scheme that needs some kind of activation. Like entering a master key into memory only - so its lost if power is lost - a technic used on some crypto cards.
A way to counter stolen devices could involve some kind of lease of keys that needs renewal on a regular basic by specifying a secret.
A way to counter an imitation/copy could be to works with a common state between the client and server that keeps changing. Like negotiating new encryption keys regularly.
We use a similar thing with our apps and web services. We call it ApiValidation where the client in each request to the service adds a header called ApiID which the server can decode to see if the client is authorized or not.
I had an idea for a fitness mobile app and I have been developing applications based on this idea for iPhone (Obj-C based), Android (java based), WebOS (html5 based) and Nokia Qt.
I now need to provide authentication to the users of my application. The server is a typical LAMP system. I would like the users of my mobile application to log in to the server seamlessly and securely.
I am not really a web programmer and hence would appreciate ideas on how I can go about providing authentication. I've heard about OpenID...but I am not sure if it can be used for authenticating mobile clients. Some one mentioned OAuth but I am not sure if a) it would work in this use case and b) What if my client does not have a Facebook/Twitter account?
Any ideas will be appreciated!
I have done something similar and used gnuTLS and a x.509 certificate to authenticate from the client side. Its seamless and easy to integrate.
https://idlebox.net/2009/apidocs/gnutls-2.6.6.zip/gnutls_7.html#SEC65
The important thing about using this method for me was that the https connection was just simple method calls and the handshaking process itself would be handled by the gnuTLS library.
My app was an iOS app and i used xcode to do it which was easy. I think it will be easier on the Java side but I am not sure about the Nokia part. The coding is in C and is thus cross platform.
However if you are looking for a iOS based solution i recommend http://developer.apple.com/library/ios/#samplecode/AdvancedURLConnections/Introduction/Intro.html
But for a cross platform solution that would require the same certificate across all applications and no input or work fro the user, I still suggest gnuTLS and using the x509 certificate.
If you already have a LAMP server somewhere, it should be fairly easy to set implement your own API for password authentication -- the important thing is that you do it via HTTPS! (so the user-ids / passwords can not be sniffed). You will need a digital certificate (CERT) for your web-server.
On your LAMP system you can keep the user data in it's database. Your LAMP server should also allow to create a local user account (of course).
You can use this solution either separate or together with OpenID or OAuth!
That means, if your client doesn't have Facebook or Twitter, they can still create an account on your LAMP server.
http://en.wikipedia.org/wiki/OAuth