I am developing an iPhone application for my client in which I have to send requests to a Secure SSL Server(Client's server, everything is ready by server side) with certificate authentication.
I am not getting exact procedure, or exact code showing steps to be followed. (i.e Procedure is not clear to me)
If anybody can explain me the mechanism behind it, it will be helpful for me.
Thank you.
You need not to do anything.
Just use proper URL with https://
All the underlying complexity will be handled by NSURLConnection class. It is as same as calling any other network services.
Related
I am trying to implement SSL pinning and I did, using the didReceiveAuthentication Challenge. I do have a question, however, is that the description of this function
https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455638-webview?language=objc
and so are the URLSession Version of it, both mentioned that only when the challenge is received. My worry is that, would there be website that doesn't ask for client certificate at all? If that is the case, how am I suppose to do SSL pinning then?
Client-side certificate pinning has nothing to do with client certificates. didReceiveAuthenticationChallenge: is called in response to receiving the server's certificate as well. In that case it's called with the protectionSpace.authenticationMethod set to NSURLAuthenticationMethodServerTrust. If the server requests a client certificate, it'll be called again with ...ClientCertificate. If Basic Auth is required, it'll be called again with ...HTTPBasic and so on.
I have a relatively successful app in the app store that allows people to view metrics on their iDevice using a JSON file hosted on the their server. The app has a simple settings screen in which you simply type the URL of your JSON file and the app takes care of visualising the data in the file. I use AFNetworking for this.
For example the URL might be: http://www.mylargecompany.com/factorykpi.json
Customers are now coming back to me and asking for the ability to connect to their servers more securely. Problem is there is a myriad of ways you can secure your server.
I need some advice. What kind of standard security features would I need to build into my app. I am confused by OAuth, HTTPS, etc.
I believe OAuth would mean the customers server would have to use it? Can you make a generic OAuth login screen in an app or do you need to know which web server you are connecting to authenticate.
Any advice on even the most basic of security measure would be very welcome!
Regards,
MonkeyBusiness
Security is really a very broad topic. There is no short answer. In any case, both web service and client app need to implement security mechanisms. I would recommend, you provide both the web service and client app.
You likely need some user login with a password, "server verifies user identity" and "client verifies server identity" using certificates. Then you utilize HTTPS which ensures to transport confident data in a secure way. The web service should be implemented with one of the well known web application frameworks since security is a scary business, and tricky. Implementing everything yourself, might end in a suboptimal insecure application.
You should now read more about the complex topic and come back when you have specific questions.
... most basic would be to use https, which would secure the transaction, but anybody accessing the same link would be able to access the same data. Thus you will need some kind of authentication, starting with a simple secret key passed as POST request, username and password and/or via certificates.
I would like to add security measurements against CSFR for my iphone app, which uses a server as backend, and the same server also serves web requests. server is written in ruby on rails.
for regular requests I'm using an special kind of authenticity token hidden inside the form, which is posted with every request from that page to establish trust.
my problem is I cannot simulate this behavior from iphone since it doesn't actually pull a form before posting.
I've thought of something along the lines of first sending request to server to generate some kind of token and then adding it to requests, but still given someone stills the token + authentication cookie etc from the iphone, sniffs it out or something. I'm still exposed to CSRF.
thoughts?
Here's an excellent post that should help to point you in the right direction.
Using ASIHTTP on the iPhone I am making HTTP requests for things such as sign up and login. They often look something like this:
http://xxxxx.com/signup.php?username=fakeusername&password=fakepassword
From this I usually receive a json response which I then parse.
I would like to soon submit my app to the App Store and need to make this secure. From what I understand this involves encryption and SSL certificates.
I have never done anything like this before and was hoping to get pointed in the right direction. Example code, tutorials, advice, etc. would be greatly appreciated.
So you've got a few questions here:
To do ssl with ASIHTTPRequest, you just need to pass a https url instead of a http one.
you don't need an real SSL certificate, you can disable validation using: [request setValidatesSecureCertificate:NO];
Yes, you're limited by what certificate signing authorities are supported by the iphone. So long as you stick to the big names it shouldn't really be an issue. (And as per 2. you can use a self signed certificate anyway.)
It seems CCATS not necessary anymore, you need an ERN instead - the process has changed, as of Summer 2010! See http://tigelane.blogspot.com/2011/01/apple-itunes-export-restrictions-on.html
for more details go through this
ASIHTTPRequest: https with SSL
I am building a RESTful API in Python with the Pylons framework, serving it with Apache2 and mod_wsgi, and would like to connect it to an iPhone app. I have very little experience with HTTPS, SSL, and certificate authorities, and I am wondering how I would go about securing my API.
How do I make sure that the API is being served through HTTPS? Is it necessary to, as in this example, set up an SSL certificate? If I sign an SSL certificate through an authority not recognized by iOS (CACert.org, for example, and mainly because it is free), will that affect my app's ability to communicate with my server? How have others solved this problem of securing communications between a web-based RESTful API and iPhone apps?
Also, how does OAuth fit into all this?
This really depends on what you mean by "securing" your API.
Do you mean that you want to A) secure it so that unauthorized people are unable to access the API or B) do you mean that you want some level of encryption on the data passed back and forth between the client and server?
If the answer is B or both, then you will definitely need to look at getting an SSL certificate and installing it on the server. Most certificate authorities have guides on how to do this.
I'm not sure what you mean by "an authority not recognized by iOS" but you should still probably consider forking out the dough for a certificate from a recognized authority. It still wouldn't hurt to try CACert.org though if they are offering free certificates. I can't really see there being any problem in terms of the ability of communication between server and client being affected.
In terms of securing your API from unauthorized clients, you could check out OAuth (see http://oauth.net/). There are various Python libraries for OAuth. Check out https://github.com/simplegeo/python-oauth2 for example. The only thing you may want to consider is that there is a reasonable learning curve when it comes to implementing OAuth.
The second link above demonstrates a simple OAuth client and also has example code for a three-legged authentication process.
You can handle certificates programmatically in iOS. You can even use self-signed certificates as long as your code acknowledges the fingerprint. I can't remember the details off the top of my head, but I know you can use didReceiveAuthenticationChallenge to do this.
In the long run, it is simpler to just buy a cert (cacert.org won't do).