Home Web Security 8 common Mobile Application vulnerabilities

8 common Mobile Application vulnerabilities


1.Binary protection: insufficient detection of Jailbreak / Root. The rooting or jailing of a device bypasses the system’s data protection and encryption systems. When a device is compromised, any form of malicious code can run on the device that can change the intended behavior of the application logic significantly. Recovery and forensic data tools usually also run on rooted devices.

Solution: In terms of security, it is best not to run the app on rooted or jail-broken devices or, at least, to detect root / jailbreak. To detect whether a device has been compromised adds an additional level of policy enforcement and risk mitigation to protect the data from exposure within the application.

2.Insufficient transport layer protection: applications often fail to encrypt network traffic when sensitive communications need to be protected. Encryption (usually TLS) must be used for all authenticated connections, in particular web pages accessible through the Internet. Backend connections should also be encrypted or risk exposing malicious actors on the same network as the application host to an authentication or a session token. These backend connections may represent a lower likelihood of exploitation than an external Internet connection, but their impact in the event of exploitation can still lead to user accounts being compromised or worse.

When sensitive data, such as credit card or health information, are transmitted, encryption should be used. Applications falling back into plaintext or forced out of encryption mode may be abused by attackers.

Solution: Ensure that the application has a security constraint that defines a secure transport guarantee based on confidentiality and integrity. This ensures that all data are sent in a way that ensures that it is not observed or altered during transmission. If TLS must be terminated at a load balancer, web application firewall or other inline host, the data in transit to the target host(s) should be re-encrypted.

3.Info Leakage–Server Version: Server information is available in the response. Information leakage is an application weakness where sensitive data, such as web application technical details, environment or user-specific data, are revealed by an application. An attacker may use sensitive data to exploit the target application, its host network or its users; leakage of sensitive data should be limited or prevented where possible.

The information leakage in its most common form is the result of one or more of the following conditions: failure to scrutinize HTML / Script comments containing sensitive information, incorrect application or server configurations or differences in page responses for valid versus invalid information.

Solution: Remove unnecessary information from server responses that could provide additional information about your network to an attacker.

4.Information Leakage–Sensitive Data: This is informatively similar to the 3 server version, but affects more leakage within the app, app-to-app, and so on.

Solution: Information Leakage usually takes place in two categories: global or resource-specific. Vulnerabilities based on global information leakages are often associated with verbose error messages or disclosures of the server / application framework. These leaks can often be solved by a setting. Leakage problems with resource-specific information relate to the disclosure of comments, files or sensitive personal information from the developer. Specific resource leakages often require direct mitigation at any time.

5.Lack of Authorization / Authentication: Lack of Authentication results when an application does not perform adequate authorization checks to ensure that the user performs a function or accesses data in accordance with the security policy.

Authorization procedures should enforce what is allowed to be done by a user, service or application. When a user is authenticated on a website, it does not necessarily mean that all content and functionality should be fully accessed by the user.

Solution: Implement a proven authorization framework that emphasizes policy – based configuration files, wherever possible, over hard – coded authentication / authorization checks.

6.Cryptography–Improper Certificate Validation: this application either does not validate SSL / TLS certificates or uses a validation system for SSL / TLS certificates that does not correctly verify that the certificate was issued by a trusted provider. If a certificate cannot be verified or is not provided, the client should be configured to drop the connection.

Any data exchanged over a connection without proper validation of the certificate could be subject to unauthorized access or modification.

Solution: Ensure that the certificate validation of your application is configured to verify correctly that a certificate is provided from a trusted source, such as a trusted certificate authority. Or code in the latest IETF or CA / B forum certificate transparency standards.

7.Brute Force–User Enumeration: There are many ways an attacker can determine whether a user exists in the system; a brute force attack is a method of determining an unknown value using an automated process to try a large number of possible values. The attack benefits from the fact that the entropy of the values is smaller than seen. For example, while an alphanumeric password of 8 characters can have 2.8 billion possible values; many people choose their passwords from a much smaller subset of common words and terms.

If error messages change if the username and/or password is incorrectly submitted, an attacker can determine the existence of a valid username / email address based on any error message differences. If the user ID is sequentially generated in a predictable manner (XXX102017, XXX112017, etc.) an attacker can enumerate the user ID through the user list.

Solution: User enumeration vulnerability typically occurs in: Login, Registration or Forgot Password. The application should not indicate the validity of a username. The response to valid and invalid input in both fields should be the same. For example, instead of ” Distress, your password is invalid, ” a correct answer could say: ” Distress, your username or password is incorrect. Try again, please. ”

8. Insufficient session expiration: after an application has been signed by the user, the identifiers used during the session should be invalidated. If the server does not invalidate the session identifiers, other users may use these identifiers to impersonate the user and act on his behalf.

Solution: First, it is a good practice to ensure that a logout button is implemented in the application; and secondly, when the user clicks this button, the session is invalidated properly.


Please enter your comment!
Please enter your name here