M6: Inadequate Privacy Controls

Overview

This article discusses the risks and impacts of inadequate privacy controls in mobile apps. It explains how personally identifiable information (PII) can be targeted by attackers and highlights the importance of protecting PII to prevent fraud, data misuse, blackmail, and other harmful activities. The article also provides insights into the common security weaknesses and technical impacts related to privacy violations, as well as the severe business impacts including legal violations, financial damage, reputational damage, and loss/theft of PII. It emphasizes the need to minimize the processing of PII and offers preventive measures such as secure data storage and communication, proper authentication and authorization, consent-based PII usage, and threat modeling. Additionally, it presents example attack scenarios involving inadequate privacy controls and references relevant resources for further information.

Description

Privacy controls are essential for protecting personally identifiable information (PII) in mobile apps. This article explores the risks, impacts, and preventive measures associated with inadequate privacy controls. It highlights the value of PII to attackers and the potential harm caused by privacy violations. The article also discusses common security weaknesses, technical impacts, and severe business impacts of privacy infringements. It emphasizes the importance of minimizing the processing of PII and provides recommendations for secure data handling. Furthermore, it presents example attack scenarios and references additional resources for in-depth understanding of privacy controls in mobile apps.

How to Prevent ?

To prevent inadequate privacy controls in mobile apps, it is crucial to minimize the processing of personally identifiable information (PII). Consider the following preventive measures: 1. Assess the necessity of processing all PII and replace or reduce sensitive information wherever possible. 2. Anonymize or blur PII by using techniques like hashing, bucketing, or noise addition. 3. Delete PII after a certain expiration period to minimize data retention. 4. Obtain user consent for optional PII usage, balancing service benefits and risks. 5. Protect PII with proper authentication and authorization when storage or transmission is necessary. 6. Implement defense in depth measures, such as encryption with sealed keys, for critical data. 7. Utilize threat modeling to identify potential privacy violation scenarios. 8. Use static and dynamic security checking tools to identify common pitfalls. By following these preventive measures, developers can significantly reduce the risk of inadequate privacy controls and protect user data effectively.

Example Attack Scenarios:

• Scenario #1: Inadequate sanitization of logs and error messages:  Logs and error messages in mobile apps may contain personally identifiable information (PII). If developers include PII in these logs or error messages without proper sanitization, it becomes accessible to platform providers, users, and potential attackers. To prevent this, developers should carefully review the information they log and ensure that exception messages are sanitized before displaying them or reporting them to a server.

• Scenario #2: Using PII in URL query parameters:  Transmitting personally identifiable information (PII) through URL query parameters is insecure, as this data is visible in server logs, website analytics, and browser history. Instead, sensitive information should be transmitted through headers or the request body to protect it from unauthorized access or exposure.

• Scenario #3: Exclusion of personal data in backups/not setting hasFragileUserData:  Inadequate configuration of data backups in mobile apps can lead to privacy violations. If personally identifiable information (PII) is not excluded from device backups or if the hasFragileUserData setting is not properly set, an attacker could obtain the backup and extract PII from the app's sandbox. Developers should ensure that sensitive data is explicitly excluded from backups and that the hasFragileUserData setting is properly configured to maintain data integrity and confidentiality.