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.

In order to explain further, I found the stored XSS in one of the top company's iOS app. They were sanitizing the user input in their web application; however, while storing and displaying, the user input was not sanitized for the web APIs used for the mobile. Thus, it allowed the attacker to store malicious JavaScripts in the database and wherever it showed the records to the user from database, it allowed the execution of JavaScripts and hence it results in the stored XSS.

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.

If an attacker is able to get the victim's token, he can use his credentials to login and can assign the victim's token using proxy to log in to the victim account.

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.