Mobile applications are part of the elements to secure as they process personal data, access sensitive information, and in some cases enable remote control of devices. Widely used for IoT devices, they are also at the core of the business model of many FinTech, HealthTech and innovative companies from various industries.
Mobile application security encompasses different aspects: the security of the mobile applications themselves (iOS or Android version), the security of the APIs and the security of the servers. Back-end security (APIs and servers) is usually more critical than front-end security (iOS / Android apps), but this depends on the technical and functional context of the application itself.
Mobile applications, key targets of cyber attacks
In general, the more data flows through mobile applications, the higher the possibility of attacks and compromises. Attackers take advantage of different types of vulnerabilities: weak server-side controls, insecure data storage, insecure data exchange, use of vulnerable third-party components, etc.
To strengthen the security of your mobile applications, it is important to investigate and fix vulnerabilities both on the server side and on the application layer (at least the APIs, but in some cases also the mobile apps themselves). In this article, we will outline the most common vulnerabilities exploited in attacks on mobile applications. We will also detail the best practices and measures to implement to fix these vulnerabilities and reduce the risks.
What are the common vulnerabilities in mobile applications and how can you protect yourself?
Server-side vulnerabilities, injection flaws and IDOR attacks
Most of the communication between an application and a user occurs through a server, as it is the server that stores and processes all the data that enables the application to run: authentication data, business data, financial or transactional data, personal data, etc. In most cases, the server-side component that enables communication and data exchange is an API.
Being a key element in the functioning of an application, the server is the prime target for attacks, which often succeed due to vulnerabilities in the server’s configuration or controls. In the event of incorrect configuration or if controls are not carried out, numerous flaws can be exploited and lead to the compromise of the data transiting, or even to the server being taken over by malicious people.
Injection flaws are the most widespread, the most dangerous and the most diverse (SQL injection, code injection, XSS, XPath, etc). They involve an attacker sending back-end requests or commands to execute malicious code if server-side controls are not in place. For example, in an SQL injection attack, by manipulating an SQL query, an attacker can retrieve database records or manipulate the contents of the database.
Server-side vulnerabilities can therefore have severe consequences. It is necessary to set up an input validation system to avoid any risk of data compromise. Furthermore, to counter the possibility of SQL injections (which are generally critical flaws), it is recommended to use prepared statements to control the information sent by a user. Indeed, if there is only one security aspect to remember in response to this problem, it is to never consider all the data sent by a user or any system as safe.
Moreover, it is on this same type of vulnerability that IDOR (Insecure Direct Object Reference) attacks are based. By relying on the lack of control of server-side permissions, it becomes possible for a user to modify the behaviour of an application, host malware, steal, alter or delete sensitive data.
To protect yourself against this type of attack, it is strongly recommended to integrate a security layer before publishing your mobile applications on the stores. Following secure development practices takes more time but can significantly reduce the risks. Once the application is ready to be released, or even after it has been published if this was not anticipated at the outset, carrying out a black box and/or grey box pentest enables you to identify and then correct all the vulnerabilities that could be exploited during attacks.
To go even further, a white box audit (source code analysis and security-oriented server configuration review) will enable to look for weaknesses by having access to the same level of information as your internal team.
Insecure data storage
A mobile application can store different types of data (cookies, text files, settings, etc.) through various storage media: SQL database, data warehouses, XML files, PLIST files, SD card, etc. Encrypting the sensitive data used in the application in an efficient way is a necessary condition to guarantee its confidentiality.
When well designed, applications running on iOS or Android store data that is not intended to be shared in a secure directory. All application data, including preferences and files, is stored in a single directory per application. Generally, only your application has direct access to this directory and no other application can access it. However, both operating systems have ways of allowing data from an application to be shared.
For example, applications can request permissions to access the user’s photo library, download folder or location. However, these features should be handled with care, as a malicious application on the device with the same permissions could read data from other applications. To reduce the risk, a best practice is to only ask for the permissions you really need.
Furthermore, rooted (Android) or jailbroken (iOS) devices allow potential malicious applications to access the data of other applications, which increases the risk of compromise. If a device is lost or stolen, an attacker will be able to recover this data more easily.
Thus, for a secure storage, it is essential that the data is protected and encrypted effectively. For mobile applications, this means encrypting all sensitive information and data stored by the application and applying appropriate permissions. Both iOS and Android offer secure storage repositories called Keychain (for iOS) and Keystore (in Android) that enable data to be encrypted.
Data Exchange Security and Man in the Middle Attacks
The functionalities of most applications are based on the communication with a server. Depending on the business needs, an application sends or receives different types of data: login credentials, user session data, personal data, bank data, etc. HTTP is the standard for client-server communication. However, communications can potentially be intercepted, modified or redirected because this protocol has no built-in security features.
Indeed, one of the common attacks uses ARP poisoning. This technique enables an attacker to hijack communication flows between an application and a gateway: router, box, etc. In short, it is a Man in The Middle attack in which an attacker sends false messages to poison a user’s ARP cache and thus link its MAC address to the legitimate IP address. By doing so, they can then intercept, modify or delete any communication that passes between the application and the server.
Protecting yourself against Man the Middle attacks is quite simple. All you have to do is use the TLS security protocol (successor of SSL) to add a security layer that guarantees the confidentiality and integrity of the data in transit thanks to data encryption. HTTP connections secured by TLS are called HTTP Secure connections (HTTPS).
Nevertheless, TLS and its predecessor SSL are not free of security flaws. Since their introduction, multiple vulnerabilities in different protocol layers or protocol implementations have been found and exploited. To address security issues, new versions of the protocol are released regularly. Using a newer version protects against known security flaws in older versions. It is therefore crucial to react quickly by installing the new versions to counter potential attacks.
Furthermore, TLS relies on digital certificates to authenticate a server to an application. These certificates must be issued (and signed) by certification authorities and have multiple characteristics that must be verified for a certificate to be valid for a given domain. However, there is a risk that attackers may issue fraudulent certificates seemingly secure, allowing them to intercept user communications.
To add an extra layer of security, it is recommended to use certificate pinning, which is an additional method of validating the server certificate. In addition to performing the classic checks on the certificate presented by the server, such as validating the certification chain to a root certificate or its validity date, the application also checks certain characteristics of the certificate, such as its serial number and the public key associated with it. This method has the advantage of being more robust than the traditional method and means that one does not have to rely solely on the system or root certification authorities to ensure that the certificate presented is the correct one.
Security of third-party components
Most mobile applications use third-party components: libraries, frameworks, third-party APIs, etc. The use of these components greatly reduces the time needed between the design of an application and its release. However, they can represent a significant security risk, with the possibility of various vulnerabilities: injections, XSS, misconfiguration, etc.
We described the security issues related to the use of third-party components in our previous article on common web application vulnerabilities and attacks. The same logic applies in the context of mobile applications. You can refer to that article for third-party component security, as well as other aspects such as authentication security, logical flaws, etc. which are also relevant to mobile applications.
Perform a mobile application penetration test to assess and strengthen your security
A good way to concretely strengthen the security of your mobile applications is to perform a penetration test. This involves testing your application by methodically testing a scope to identify security flaws and suggest appropriate fixes.
A mobile application penetration test enables the identification of vulnerabilities on the server layer as well as on the application layer (web application vulnerabilities for APIs and mobile application vulnerabilities for iOS and Android apps). The tests combine a static and a dynamic analysis of the mobile application.
Examples of server-side vulnerabilities:
- Open insecure services
- Outdated software
- Bypass of security elements
- Configuration errors
Examples of flaws in web applications (OWASP Top 10 Web):
- Injection flaws
- Authentication and session management vulnerabilities
- Sensitive data exposure
- XML External Entities
- Broken Access Control
- Security misconfiguration
- Cross-Site Scripting (XSS)
- Insecure Deserialization
- Use of components with known vulnerabilities
- Insufficient logging and monitoring
Examples of vulnerabilities in mobile applications (OWASP Top 10 Mobile):
- Improper platform usage
- Insecure data storage
- Insecure communication
- Insecure authentication
- Insufficient cryptography
- Insecure authorisation
- Client code quality
- Code tampering
- Reverse engineering
- Extraneous functionality
Furthermore, unlike a vulnerability scanner, a penetration test is not limited to the discovery of vulnerabilities but includes an exploitation phase, carried out manually by the pentesters. It enables, just as a malicious individual would do, to use the identified flaws to potentially discover other vulnerabilities, and thus to test the security of your mobile applications more effectively.
The penetration test will be more or less thorough, and the pentesters will be more or less exhaustive in the search for flaws, depending on the scope and the conditions defined for the service. It is recommended to perform at least black box tests, i.e. to search for vulnerabilities on the scope that is accessible to an external attacker. For a mobile API testing, it is generally recommended to perform grey box testing to enable the pentesters to handle the API correctly and to save time in identifying the most important security flaws. For tests aimed at ensuring the highest level of security, white box testing enables a deeper investigation, which requires providing the pentesters with access to the mobile application’s source code and server infrastructure.
Regardless of the approach chosen, the result of a penetration test is a technical report detailing the vulnerabilities identified and the fixes to implement.
Vaadata assists companies of all sizes and in all industries with mobile applications penetration testing. Our offers are tailored to the security challenges, the level of risk exposure and the budget of both startups and large companies. To test a mobile application, a budget ranging from €1,500 to €10,000 is generally required, depending on the functional and technical complexity of the application, as well as the level of depth required for the tests.
Feel free to reach us for any question regarding a penetration testing project on a mobile application.