I'm setting up a server to do receipt verification for IAP on the App Store.
My question is: Should I make the connection between the iOS device and my server as a https connection, or does http suffice? All the examples I seen people are just using http.
It seems that if I use http, then it's venerable to a someone redirecting the DNS. Or does that not matter? Seems like it would.
Of course, I'm such small potatoes that it's probably not worth the hassle.
It is always desirable to use https (encrypted) connection when you are passing some credentials or sensitive information such as financial transactions. May be it is not possible for anyone to mangle the transaction itself but still, you are breaching the confidentiality aspect of financial transactions which your client might not like.
However, it is not just https which can help, you can also implement your custom encryption in the application to make the communication secure (may be the security is not strong but does work in cases where you really do not need an overkill). Try to encrypt the data with a pre-shared key and decrypt it on the server (which I do myself many times).
Related
I'm an iOS Developer and I have one question about security that I can't answer.
Security experts say that using the "certificate pinning" will make your app more secure (for example against man in the middle attacks).
I agree that with this technique you can guarantee that your app is communicating with your backend (and that no-one "in the middle" can sniff the traffic), but as we are using HTTPS, the traffic is already encrypted, so how could someone see the traffic?
There is one possible way, that you get the certificate of the attacker and you install it on your iPhone, but is this really something that can happen ? Or are other ways to make this kind of attack?
HTTPS and Ceritificate Pinning
Security experts say that using the "certificate pinning" will make your app more secure (for example against man in the middle attacks).
That a best practice in terms of security in order to avoid the MitM attacks that you already know, but do you know what certificate pinning works?
I know that your question is about iOS but in my article Securing HTTPS with Certificate Pinning on Android you can learn for what certificate pinning is for and why is needed, because this is agnostic of the mobile platform being used. Please read the article and feel free to ignore the part about implementing pinning in Android.
To give you some context I will quote some of the more relevant parts of my article, that will help clarifying your doubts.
Lets' start with the part about why we need Certificate Pinning:
While HTTPS gives you confidentiality, integrity and authenticity in the communication channel between the mobile app and the API server, certificate pinning will protect these same guarantees from being broken.
Let's see two examples from the article on how the HTTPS guarantees can be broken.
First Example:
To prevent trust based assumptions
Incorrectly issuing leaf certificates to the wrong domain names by Root and Intermediate Certificate Authorities (CAs) would allow an attacker to intercept any HTTPS traffic using them, without the end user noticing anything.
Do you think that is very unlike for this to happen? Just take a look to the famous cases of DigiNotar, GlobalSign and Comodo.
Second Example
Another scenario where the HTTPS guarantees are usually broken is when the device is running in hostile environments:
A good example of a hostile environment is public WiFi, where users can be tricked by an attacker into installing a self signed root certificate authority into the trusted store of the device as a requirement for them to have internet for free. This will allow the attacker to perform a MitM attack and intercept, modify or redirect all HTTPS traffic, because the device will now accept all intercept traffic which is now signed by the root CA of the attacker - now trusted by the device.
Both examples will allow for attackers to see the HTTPS encrypted, thus I hope it answers your question:
I agree that with this technique you can guarantee that your app is communicating with your backend (and that no-one "in the middle" can sniff the traffic), but as we are using HTTPS, the traffic is already encrypted, so how could someone see the traffic?
So, HTTPS will encrypted your traffic in transit and certificate pinning will try to prevent it from being decrypted. Wait, did you said try? Yes, because pinning can also be bypassed in a device the attacker controls. I have several articles (1, 2) on it, but on Android, and for iOS it can also be done, and its on my backlog, thus I will update this answer when done.
Possible Attacks to your Mobile App
There is one possible way, that you get the certificate of the attacker and you install it on your iPhone, but is this really something that can happen ? Or are other ways to make this kind of attack?
An attacker will reverse engineer your mobile app in order to understand how everything fits together and will try then to exploit flaws in your logic and security. For example, the attacker can use the MobSF - Mobile Security Framework to statically reverse engineer your mobile app binary:
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
Attackers will often perform attacks to your code at runtime to modify its behaviour or bypass certificate pinning and a popular tool used for this propose is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
Bear in mind that the attacker can be a legit user of your mobile app trying to bypass some of the limitations of the plan is on in order to get more then what he is entitled to.
Want to Implement Certificate Pinning on iOS?
If you want to go ahead and implement certificate pinning in your iOS mobile app then you can use the Mobile Certificate Pinning Generator free tool to get the iOS configuration generated for you.
First you need to provide the API domains you want to pin:
After you submit the form you need to go to the iOS tab to see your iOS configuration and copy/paste it into your mobile app code:
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
Yes, you need to install a root CA certificate on the iOS device and trust it for making an man-in-the-middle attack on an HTTPS connection used by an iOS app.
But you forget one major case: What happens if the attacker and the iPhone user are the same person? Having access to the transmitted data makes it easier to analyze you app and find potential flaws. So an attacker can install your app on a prepared device, analyze it, find all the mistakes you made and afterwards attack use this knowledge to attack your server(s) and/or your app users.
Another scenario is that people are forced to install root CA certificates may be because the phone is used in a company with own network inspection or at a border control.
Last but not least the recent attack on KlaySwap crypto shows you why certificate pinning is so important: in that attack the BGP was attacked to redirect traffic to a specific web server hosting a JavaScript file to a malicious server. After redirecting the traffic the attackers just used ZeroSSL to create a new 100% valid SSL/TLS certificate which they installed on their malicious redirected web server.
Say I configured my NGINX server with SSL and
I am able to establish and keep a server sent events connection
to my Rails server.
Would every message from thereon from Rails to my browser be
undecipherable to any prying eyes on the Internet.
Moreover would I be even able to establish such a connection? Since all I hear is that SSE works over http.
Yes.
Be aware that connecting from an http html page to an https SSE URL counts as a different origin, meaning you will hit CORS restrictions.
According to a footnote in my book (Data Push Apps With HTML5 SSE) Chrome was not accepting self-signed SSL certificates for use with SSE, as of early 2014. (But it was also not accepting them for XMLHttpRequest, i.e. ajax, either.) (A quick search shows people still posting bug reports about self-signed certificates not working, so this might still be the case.)
I have an iPhone app that uses a Rails server HTTP API. The API is public at this point - no authorisation is required to get the data.
Currently anyone can go to API's URL and download the data.
http://server.com/mydata
The data is not very sensitive. But I still want to prevent people from easily getting it. What are the ways of doing that? I do not want iOS app users to log in either.
Current solution I have
iPhone app adds a secret token to the HTTP header or query of the request. The data goes over HTTPS.
https://server.com/mydata?secret=my_secret
Is there a better approach?
You could try an approach where the client is only allowed X number of requests per time period (based on IP address or username)
HTTPS is extremely easy to man in the middle on a device you control. You can do SSL cert validation, but there is always someone out there with more time, so best off to handle it server side.
Distribute and use your own SSL certificate.
Apps that transfer sensitive customer data, like credit card and payment information, must be protected from man-in-the middle attacks. The best protection is a mutual authentication scheme, where certificates are exchanged to make sure the app is connected to a trusted server and to make sure the server is connected to a trusted app.
Then only individuals (who have presumably installed your application) have access. If someone digs through the code and gets the public certificate then they can impersonate the client; but at that point they win anyway and two-factor authentication should be explored.
I'm fairly new to SSL and secure connections in general. What are the major steps required for an iOS app to talk to a server over a secure communications channel?
I'm aware that an SSL certificate will probably be necessary. I'm planning to purchase one from a trusted certificate authority. However I'm not sure if both the app and the server need certificates or if it's just the server. Also I'm not sure how to handle SSL errors. Perhaps there's a library that can help with this like ASIHTTPRequest or similar.
If you are using HTTPS as your protocol for communication and have valid certificates on your server all that should be required is changing your http:// to https:// on your client. For HTTP libraries a very popular option now is AFNetworking. It is a bit better maintained than ASI and has some nice block features not supported by ASI.
As far as SSL errors, it is usually a good idea to present the warnings to end users (through alert views or some other means). They could point to real security attacks (but more likely will point to miss configured or expired certificates).
For an ios 5.0 application connecting to a rest webservice, the customer wants to implement a token based security to ensure that the data being sent over the network is not intercepted and altered in any way... Doesn't https over ssl ensure that the data is not intercepted? and I thought that this would be enough. Pls advise
However, The way the client wants it to work is that starting with the first client authentication request the server would return a token id that would be used to send the next request. In the response for this next request another token id would be sent back that needs to be used for the next request and so on. The problem is of concurrency. Eg when the apns token comes back and the app has to send that to the server and if at that time the iOS application is already making a data request to the server, then the tokens to be used will not match. also since the app has to regularly poll the server for new items, then there are more chances of such concurrency issues to occur.. Any ideas what efficient solutions I can put in the app to counter this?
Or if anyone can suggest better ways of implementing security over the network data, as a possible alternative to the above approach.. solutions that would work for an iOS app and is not battery consuming?
Help in this would be greeeeaaatly appreciated! :-)
Ps. Jfyi Am already doing md5 security on the token being sent
Doesn't https over ssl ensure that the data is not intercepted?
It depends on whom you're trying to protect agains. Plain SSL will protect perfectly fine against anyone between the device and the server.
But it will be trivial for the device owner to create a man-in-the-middle against a client that trusts all CA's on the device. All he needs to do is install his own private CA-certificate on the device, issue a fake certificate for your server signed by this CA, and install this certificate on his proxy/MitM device. To avoid this attack you'd need to do certificate pinning in the App.