To conduct a security assessment of the iOS application, you need to follow some standard criteria from industry. Open Web Application Security Project (OWASP) Top 10 Mobile Risks is the list of vulnerabilities that are usually found in iOS applications.
You can always find latest top ten list for mobile at https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks.
The major difference between the latest OWASP Top 10 Mobile Risks and its earlier versions is the introduction of a new vulnerability in the list, that is, the lack of binary protection, which is the replacement of sensitive information disclosure.
The latest OWASP Top 10 Mobile Risks, Year 2014 list covers the following vulnerabilities:
Nowadays, most of the apps are hybrid apps where they use native app code or web view to design UI and in backend, they use web APIs to communicate with the server. As there are web apps in backend, so almost all attacks that target web applications are applicable to iOS apps as well. If you have never checked web attacks, I would encourage you to go through OWASP Top 10 Web Application Risks at https://www.owasp.org/index.php/Top_10_2013-Top_10.
Insecure data storage is all about storing the data insecurely on the device. Many times, an application uses simple plist files or unencrypted database to store sensitive information such as passwords or other user-related information.
This is the most frequent and, sometimes, very easy-to-find vulnerability. An application should never store sensitive data such as the users' personal, financial, or healthcare information in plain text format. If app developers are storing sensitive information, it may be non-compliant with various compliance standards such as Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA), and so on. We will look into this vulnerability in detail, such as various formats of storage, and how to look into this data in the upcoming chapters.
Insufficient transport layer protection is all about how to send your data across the network. Mobile apps are frequent victims of coffee shop attacks and if an application is sending sensitive data, such as credentials, access tokens, and so on, over HTTP, then any attacker sniffing over the network can easily catch or modify it.
Even if the developer is sending data over HTTPS; however, if he does not validate the sever-side certificates, then it is vulnerable to SSL pinning such as attacks where the attacker performs man-in-the-middle (MITM) attacks with self-signed certificates.
Side channel data leakage arises when a developer places sensitive information or data in a location on the mobile where it is easily accessible by other application. Thus, resulting in a side channel data leakage.
In one of my financial application assessment, the application was taking credit card details from the user and had not implemented any security mechanism to deal with side channel data leakage. Now, in iOS, whenever we background the app, it takes its screenshot and stores it on the device.
An attacker having physical access can easily download application files and access the screenshot that was revealing the victim's credit card details.
Similar to application screenshots, there are various ways such as device logs, pasteboard, cookies, and so on, where the application may leak sensitive data.
In my security assessment, I have reported the login bypass vulnerability in many of the top applications, where the authenticating user was only at the client side. If you put proxy and change the server-side response, you are more likely to be logged in with wrong passwords.
So, as this case study suggests, never reply only on client-side controls for authentication. If you are using OAuth-like authentication schemas, make sure you store tokens on the client device securely. Attacker can easily bypass login on the victim device with leaked tokens.
Nowadays, most of the applications use web APIs to authenticate the users rather than storing credentials locally on the device. In such a scenario, all your web application security attacks are applicable, such as:
Broken cryptography is all about using insecure cryptographic functions to encrypt or hash user data on a device. Are you using MD5 to hash the user's password? Are you not adding any salt to the hashed data? Is your app leaking encryption keys somewhere in the local code? These are a few examples where we need to implement secure cryptographic functions with proper implementation schemas.
Have you ever done SQL injection attack in web app? If yes, then you are good to go with similar attacks in an iOS application. If the developers are not sanitizing user input, then these apps are vulnerable to injection attacks as well. We will perform a SQL injection-like attacks on iOS application in Chapter 3, Identifying the Flaws in Local Storage.
Security decisions via untrusted input is about performing actions without proper validation or authorization check of the user. Does your application have functionality to call any number? Do you prompt the user before initiating a call? Are you checking whether the caller is a logged-in user? If not, you are more likely vulnerable to security decisions via untrusted input attack.
Improper session handling is managing the user's session token insecurely. Many times, the developers do not invalidate session tokens at user logout. So, the attacker can reuse these tokens for unauthorized logins.
Lack of binary protections is about checking protections of binary. Checking whether the application allows attackers to reverse engineer the application source code is very important in case of application handling, as the user's sensitive data should not allow the attackers to entirely decompile the application. We can also check whether binary has implemented any protection for stack smashing attacks or implemented address space layout randomization (ASLR) in order to prevent memory corruption attacks.
We will study these concepts practically with more details in the upcoming chapters.