If I open arbitrary urls in my ios application, will I have to do my own malware/phishing/etc... checks? Does the webview (implicitly) do any work on my behalf (or would i have to switch a setting somewhere?)?
In short: no.
UIWebView only has some restricts about javascript same-origin policy, and iOS has it's own SSL Certificates Validation (TLS Chain Validation) which can help UIWebView a little bit safe.
If you want to check malware, phisinng, ... you're free to do it.
No, it uses Webkit under the hood, which does not check for malwares, but it may give you only hints on expired certificates, self-signed certificates or invalid ones.
You should implement a request filter, which performs better SSL checks for valid certificates and uses some third-party anti-malware / dangerous domains and keep them out. In that case, you just ignore "that" request.
Related
When the webhosting option is activated for an app in Back4App, getting a subdomain like http://someapp.back4app.io, if you access someapp.back4app.io http is used by default instead of https.
Regarding to this I only found https://blog.back4app.com/2017/11/09/parse-server-best-practices/ but that speaks only about checking via javascript the http/https protocol in every page/function/api-endpoint, and redirecting if it's not https, quite tedious.
Is there a way to globally redirect any http request to my Back4App pages to https?
I checked with the Back4app's Support Team and, in that case, it's possible to do only on Dedicated Plans. For more info, I kindly ask you to contact them.
In my app, I've set up SSL Pinning on all my REST requests with the help of AFNetworking. This helps prevent MITM attacks. When I test my app using Charles proxy as the "man in the middle", the requests fail as expected. However, this is not the case for my login flow (Oauth 2.0) via SFSafariViewController. That is because ... this process of logging in is unrelated to AFNetworking.
I believe the problem could be solved if there was a way to achieve SSL Pinning on SFSafariViewController.
1) Is there a way to do this? I could not find anything online about this.
2) What are some ways people go about solving this problem? It seems like it is a security issue.
To me the following comment makes sense.
there is no way to do any SSL pinning in SFSafariViewController, for two reasons:
The SFSafariViewController class does not provide any API for
customizing SSL validation and handling authentication challenges.
When used, the SFSafariViewController is actually run in a separate
process and the app's code has no access to it at all. Hence
swizzling does not affect the SFSafariViewController as it only
happens in the app's process.
Reference:-
https://github.com/datatheorem/TrustKit/issues/163
You could use WKWebView (WebKit) and create your own version of SFSafariViewController that has your pinning for where you use SFSafariViewController, but you can not certificate pin in SFSafariViewController. If you are using SFSafariViewController for downloading configuration profiles, then you are stuck, no cert pinning allowed and WKWebView will not "store" configuration profiles for installation, only Safari.app and SFSafariViewController can do that, to my knowledge.
I have a question about one of new features in iOS 7 - Single Sign On.
Are there any detailed info about it? Has somebody already tried it for implementation? I searched a lot of articles and docs - but did not find any useful. I also did not find any detailed info on Apple and Developers Apple resources. There are no visual setting for SSO in iOS 7 GM version (I am not sure if it should be there).
So my question is - have somebody already investigated it and may be somebody can share some links and useful info? Are there any technical descriptions of this feature and is it existed some how in iOS 7 GM?
Thanks in advance.
I would recommend watching WWDC 2013 Session 301 "Extending Your Apps for Enterprise and Education Use"
Also, for an overview of an implementation of this functionality this site helps.
Lastly, here is Apple's documentation (available to developers). Look for the heading: Single Sign-On Account Payload.
Configuring SSO on a device will require Apple Configurator to install the profile or an MDM solution for OTA delivery of the SSO profile.
To make SSO (Kerberos) working on iOS7 you need 3 things:
On the server side: Kerberos environment + HTTP SPNego/Kerberos authentication configured. SSO in iOS works only for HTTP(S).
Configuration profile containing:
[Obligatory] Your Kerberos realm.
[Obligatory] Your Kerberos principal (usually username), this can be left empty - in that case user will be asked to specify it during the profile installation.
[Obligatory] List of URL prefixes of the pages allowed to use SSO. Wildcards cannot be used here, if the prefix doesn't end with slash character, it will be automatically appended to it.
[Optional] List of bundle IDs allowed to use SSO, if empty all applications are allowed. Wildcards in bundle IDs can be used.
Application that supports it, Safari and WebKit (UIWebView class) do. As described in WWDC 2013 Session Videos number 301, you have to use either NSURLConnection or NSURLSession class. This is a simplified example of the HTTP traffic when authenticating using the SPNego scheme:
Client: GET https://login.example.com/adfs/ls/auth/integrated/?data1=aa&data2=...
Server: 401 Unathorized
+header WWW-Authentificate: Negotiate
Client: GET https://login.example.com/adfs/ls/auth/integrated/?data1=aa&data2=...
+header Authorization: Negotiate [SPNegotInitToken]
Server: 200 OK
+header Authorization: Negotiate [SpnegoTargToken]
+header set-cookie [SESSIONID]
The dialog with prompt for the Kerberos password (if the Kerberos ticket has not yet been granted/expired) will appear after receiving "WWW-Authentificate". Obj-C classes will handle automatically all the redirects and authentication process, so the only thing you need is to make a request to the login URL and allow this URL in the profile.
Enterprise Single Sign On lets user sign in once on their device and let all apps on device use it fo authentication.In case of twitter, links below will be useful for you,
https://dev.twitter.com/discussions/8231.
http://eflorenzano.com/blog/2012/04/18/using-twitter-ios5-integration-single-sign-on/
I'm working on an iOS app with a rails backend, running on a VPS (via my own domain).
My question is: is it insecure to use a self-signed SSL certificate on my server and ignore the warnings from NSURLConnection while communicating with it, considering that this is a private API which is only accessible via my iOS app?
The safe way to go in this scenario is: Sign it yourself and manually add the certificate to the local certificate database of every system you work from, so you don't need authentication to know it's yours. Sometimes this can be done automatically as easily as checking the box "ignore the warning for this certificate" the first time you connect from each system, which will prevent you from seen it again on that system unless the certificate changes.
This way you won't see the warning again, unless it's somebody else's self certificate you're looking at.
Ignoring the warning by default usually means that if somebody else signs its own certificate and presents it to you, you will go along without even noticing. Not a good idea.
I need to establish a HTTPS 2-way SSL connection from my iPhone application to the customer's server.
However I don't see any secure way to deliver the client side certificates to the application (it's an e-banking app, so security is really an issue).
From what I have found so far the only way that the app would be able to access the certificate is to provide it pre-bundeled with the application itself, or expose an URL from which it could be fetched (IPhone app with SSL client certs).
The thing is that neither of this two ways prevent some third party to get the certificate, which if accepted as a risk eliminates the need for 2-way SSL (since anyone can have the client certificate).
The whole security protocol should look like this:
- HTTPS 2-way SSL to authenticate the application
- OTP (token) based user registration (client side key pair generated at this step)
- SOAP / WSS XML-Signature (requests signed by the keys generated earlier)
Any idea on how to establish the first layer of security (HTTPS) ?
Ok, so to answer my own question...
It turned out that the security has no fixed scale of measurement.
The security requirements are satisfied as long as the price for braking the system is significantly above the prize that one would get for doing so.
In my situation we are talking about e-banking system, but with somewhat low monthly limits (couple of thousands USD).
As I mentioned in my question there would be another layer of security above the HTTPS which will feature WSS XML-Signatures. The process of registering the user and accepting the his public key is also done in several steps. In the first step the user sends his telephone number together with a cod retrieved somehow from my client. Then an SMS is sent to the user with a confirmation code. The user enters the confirmation code into a OTP calculator that would produce OTP code which will identify the user. Then the public key is sent to the server together with the OTP code. From here on every request would be signed by the private counterpart of the public key sent to the server earlier.
So the biggest weakness for the whole process is that of someone reverse engineers the application and retrieves the client certificate used for the SLL. The only problem arising from this is that someone might observe users' transactions. However in order for someone to make a transaction he would need the user's private key, which is generated, encrypted and stored into the keychain. And the price for braking this security level is VERY HIGH.
We will additionally think on how to protect the users' data on a higher level (e.g. using WSS Encryption), but for the start I thing we are good with the current solution.
any opinion ?
regards
https doesn't really work this way. In a nutshell, you attach to a secure server where the certificates are signed by a well known authority.
If you use Apples (iPhone) classes for this, they will only accept 'good' certificates. By good, I mean what Apple deems as acceptable. If you don't use them (there are alternatives in the SDK), you won't be able to connect (except, maybe, in the case where you have an 'Enterprise' developers license - but I can't say that with 100% certainty as I haven't looked enough at this license to be sure)
To continue, use your https connection to your correctly signed website and then institute some sort of login with a built in username/password, or challenge/response based upon the unique ID of the iPhone (for example) and exchange keys using that connection.
Note that this means that your application will have to query for new certificates at (each connection/every X connections/every month/application specified intervals) to keep them up to date. You can then use these certificates to connect to the more secure server.
[edit]
Check this post - may have more information about what you're asking to do
[/edit]
[edit2]
Please note that the request is iphone, not OSX - app store approval is an issue
[/edit2]