Insufficient Jailbreak / Root Detection. Rooting or jailbreaking a device circumvents data protection and encryption schemes on the system. When a device has been compromised, any form of malicious code can run on the device, which can significantly alter the intended behaviors of the application logic. Recovery and data forensic tools generally run on rooted devices as well.
Solution:
With regards to security, it is best to not have the app run on rooted or jailbroken devices, or to at least do some form of root/jailbreak detection. Detecting whether a device has been compromised adds an extra layer of policy enforcement and risk mitigation to protect the data within the application from being exposed.
2. Insufficient Transport Layer Protection:
: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. Encryption (usually TLS) must be used for all authenticated connections, especially Internet-accessible web pages. Backend connections should be encrypted as well, or risk exposing an authentication or session token to malicious actors on the same network as the application host. These backend connections may represent a lower likelihood of exploitation than a connection over the external Internet; however, their impact in the case of exploitation can still result in compromise of user accounts or worse.
Encryption should be used whenever sensitive data, such as credit card or health information, is transmitted. Applications that fall back to plaintext or otherwise be forced out of an encrypting mode can be abused by attackers
Solution:
Ensure the application has a security constraint that defines a confidentiality and integrity-based secure transport guarantee. This will ensure that all data is sent in a manner that guarantees it cannot be observed or changed during transmission. If TLS must be terminated at a load balancer, web application firewall, or other in-line host, it should re-encrypt the data in transit to the target host(s).
3. Information Leakage – Server Version:
Server information is present in the response. Information Leakage is an application weakness where an application reveals sensitive data, such as technical details of the web application, environment, or user-specific data. Sensitive data may be used by an attacker to exploit the target application, its hosting network, or its users; leakage of sensitive data should be limited or prevented whenever possible.
Information Leakage, in its most common form, is the result of one or more of the following conditions: A failure to scrub out HTML/Script comments containing sensitive information, improper application or server configurations, or differences in page responses for valid versus invalid data.
Solution: Remove unnecessary information from server responses that could give an attacker extra information regarding your network.
4. Information Leakage –
Sensitive Data: Informationally this is similar to the Server version in 3, but touches on more leakage within the app, app-to-app, etc.
Solution:
Information Leakage generally occurs in two categories: globally or resource specific. Vulnerabilities based on global information leakages are often related to verbose error messages or server / application framework version disclosures. These leakages can often be solved by a configuration setting. Resource-specific information leakage issues are related to the disclosure of developer comments, files or sensitive personal information. Resource-specific leakages often require direct mitigation each time they occur.
5. Insufficient Authorization/Authentication:
Insufficient Authorization results when an application does not perform adequate authorization checks to ensure that the user is performing a function or accessing data in a manner consistent with the security policy.
Authorization procedures should enforce what a user, service, or application is permitted to do. When a user is authenticated to a web site, it does not necessarily mean that the user should have full access to all content and functionality.
Solution: Enforce a proven authorization framework scheme which emphasizes policy-based configuration files over hard coded authentication/authorization checks wherever possible.
6. Cryptography – Improper Certificate Validation:
This application is either not validating SSL/TLS certificates or is utilizing an SSL/TLS certificate validation system that will not correctly verify that a trusted provider issued the certificate. The client should be configured to drop the connection if the certificate cannot be verified, or is not provided. Any data exchanged over a connection where the certificate has not properly been validated could be exposed to unauthorized access or modification.
Solution:
Ensure that your application’s certificate validation is configured to correctly verify that a certificate is provided, and from a trusted source like a reliable Certificate Authority. Or, code-in the latest certificate transparency standards approved by IETF or the CA/B Forum
7. Brute Force – User Enumeration:
There are numerous ways for an attacker to determine if a user exists in the system; a brute force attack is a method to determine an unknown value by using an automated process to try a large number of possible values. The attack takes advantage of the fact that the entropy of the values is smaller than perceived. For example, while an 8-character alphanumeric password can have 2.8 trillion possible values, many people will select their passwords from a much smaller subset consisting of common words
.jpeg)
0 Comments