First of all, you need to understand what happens during the process of the local authentication. Here, the application authenticates the user against the credentials. Those credentials are stored on the device locally. So, let’s say that the user unlocked the application. He might unlock some inner layer too or a functionality by providing a valid PIN, a fingerprint maybe or a password and more. Those are the things which are actually verified by the data references. Why is this done? Because the users can after that more conveniently to resume some existing session and all that by using the remote service. What they will get is that the authentication will basically step-up and easily protect some of the critical functions.
There are so much different methods available on the iOS when it comes to integrating some local authentication into the application. What provides a set of the APIs is actually the Local Authentication framework. It provides it for the developers so they could extend the authentication dialog to the user. Sometimes it is also possible to enable the Keychain to implement the local authentication. Also, it is very recommended when it comes to connecting to a remote device.
Touch ID. This is actually a fingerprint authentication on the iOS. Here, the ID sensors which come from the fingerprints are operated by the SecureEnclave security coprocessor. Also, they don’t expose the data of the fingerprint to any other part which exists on the system.
Here, the developers know two ways when they want to incorporate the Touch ID authentication. The first one is LocalAuthentication.framework. This is basically a high-level API. It can be used for authenticating the user through the Touch ID. What happens next is that the application isn’t allowed anymore to have the access to any of the data which is being associated with a fingerprint that is enrolled. Also, it becomes notified only in a situation when it’s mentioned that the authentication itself was successfully done. The second way is through Security.framework. A lower level of API, although it may access the Keychain Services. Also, a good option because it is more secure when the application needs to protect some of the secret data with the biometric authentication. It needs to be done that way because the access control is managed on the system-level, and in that case, it can’t be bypassed that easily. Also, this option has a C API but also contains some open source wrappers available. Through them, it is making the access to the Keychain very simple, like NSUserDefaults. It is underlying LocalAuthentication.framework. The Apple is always recommending the default to be on the higher level of APIs whenever that can be provided.
When it comes to static analysis, you must verify that the kSecAccessControlUserPresence policy and also the kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly protection classes are actually set when the method SecAccessControlCreateWithFlags called.
About the dynamic analysis, you need to remember that if you have the jailbroken device, let’s say the Swizzler2, you can easily bypass the LocalAuthentication, but you need to follow some steps.
1.Settings-Swizzler;
2.Then enable the ”Inject Swizzler into Apps”;
3.”Log Everything to Syslog”;
4.”Log Everything to File”;
5.Then enter the submenu named ”iOS Frameworks”;
6.”Local Authentication” enabling;
7.submenu ”Select Target Apps”;
8.then enable them;
9.close the app and go through the process again;
10.once the TouchID shows just click the cancel button.
Framework of the local authentication
It is providing the facilities with a purpose to request a passphrase. Also, it may want to request a TouchID from the users too. How can developers display and utilize the authentication prompting? They do it through utilizing the function evalutePolicy which is of the class LAContext.
There exist the two policies which can define the acceptable forms of the authentication. Those are deviceOwnerAuthentication, or also known as Swift. It may be also recognized as LAPolicyDeviceOwnerAuthentication or Objective-C. Here, the user can be easily prompted and perform the TouchID authenticating. If it is not activated, the passcode of the device will be requested. But what if the passcode is not available? Then, there is no other possible option that will happen but that the policy evaluation will fail.
The second form-deviceOwnerAuthenticationWithBiometrics-Swift, or also LAPolicyDeviceOwnerAuthenticaionWithBiometrics or Objective-C means that the authentication will be always restricted to the biometrics everywhere the user is prompted for the TouchID.
You need to know also that you can use the iOS Keychain APIs when you want to implement the local authentication. Here, the application will store the items coming from the Keychain and it will happen only if the user’s TouchID already passed the authentication process.
Also, keep in mind that the Local Authentication framework is actually the event-based procedure. That means it won’t solve the method of the authentication. It can be easily bypassed by patching or some instrumentation, but not on all the levels. It may be successful at the user-interface level. Besides that, the Keychain service method will keep safe triggering payment transactions which may happen when re-authenticating. It will keep safe all of the sensitive data too.
How to test the custom URL schemes?
We will talk about the platform interaction on iOS now. When you compare Android’s rich Inter-Process Communication capabilities to iOS, you will easily realize how the iOS actually offers so many options when it comes to communicating between the apps. Of course, if you look at the fact, actually the direct communication for the applications doesn’t exist.
So, here we have the Apple who is offering the two types of the indirect communicating. Those are a file transfer which goes through the AirDrop, and the second option is by the custom URL schemes.
The second option will allow the applications to communicate through some of the custom protocols. But, first, the app needs here a declared support for that scheme and to handle the URLs which are incoming and that also use the same scheme. Let’s say the URL is registered, what happens? In such a situation the other applications can open also the registered scheme. Besides that, they will also easily pass the parameters and all that by creating the appropriately formatted URLs. They will also need to make it through the openURL method.
When the security issues arise? They become stronger and more usual when the application processes call them to its URL scheme. And all that happens even without the proper validation of the URL and also its parameters. Then, the users are the ones which are not prompted for confirmation before they can even trigger the important action they want.
The example of such a bug would definitely be the problem in the Skype Mobile app. It was discovered few years ago. The app registered the skype:/ / protocol handler. It allowed the other apps to have the permission to trigger the calls to that Skype users and also the phone numbers. Frightening, right? Also, what was the problem here is that the Skype didn’t even ask the users for the permission before the calls were done. So, basically, it could be any app that called the arbitrary numbers without even using the knowledge.
What would be the first step when it comes to testing the custom URL schemes? That would definitely be to find out if the app registers have any protocol handlers. You can find that information in the file named info.plist. It is placed in the sandbox app folder. If you want to view what are the registered protocol handlers, then you will need to open a project in the Xcode. There you will find the Info tab and you will open the URL types section. If this sounds confusing, don’t worry, it is actually the most simple action.
After you have finished this, you will need to determine how the URL’s path was built and also validated. Here, the method OpenURL will be very useful for you, because it is actually responsible when it comes to handling the user URLs. Check out the controls which are implemented and see how are the URLs validated and if they require the user’s permission when someone wants to use the custom URL scheme.
Once this action is completed totally, you will see it in the Info.plist. You will find there the registered protocol handlers too. If you want to find the URL structure, then you should check out the uses of the CFBundleURLSchemes key. You can do it by using the strings or even Hopper.
So, let’s say that you have identified the custom URL scheme on which the application is actually registered. You now need to open the URLs in Safari and also to observe totally how is the application behaving during the different processes and actions.
Also, I would like you to remember that before calling the URL, you must be sure that you have validated it carefully. How can you do it? Easily, through the whitelist application. It may be opened through the registered protocol handler. Another helpful control here would be definitely to prompt the users to confirm the URL action which is invoked.
I really hope that you have learned about the Android and iOS platforms and most of-testing. If you realized their differences, and I am sure that you did, you will easily go through this process and enjoy the knowledge you got from our mobile device testing. s