Skip to content

Latest commit

 

History

History
30 lines (25 loc) · 4.24 KB

attack-surface.md

File metadata and controls

30 lines (25 loc) · 4.24 KB

Attack Surface Analysis for square/leakcanary

Attack Surface: Heap Dump Data Exposure

  • Description: Sensitive data residing in the application's memory at the time of a heap dump can be exposed if the heap dump file is accessed by unauthorized parties.
  • How LeakCanary Contributes: LeakCanary generates heap dumps (HPROF files) as its core mechanism for analyzing memory leaks. These files are the direct source of this risk.
  • Example: An attacker gains access to the application's private storage directory on a compromised device and copies the HPROF files generated by LeakCanary. The attacker then uses a tool like Eclipse Memory Analyzer (MAT) to open the HPROF file and views strings, objects, and other data, finding API keys, user tokens, or personal information.
  • Impact: Confidentiality breach; potential exposure of user data, credentials, API keys, or other sensitive information.
  • Risk Severity: Critical (if sensitive data is present in memory and not handled securely) or High (depending on the sensitivity of the data).
  • Mitigation Strategies:
    • Disable in Production: The most crucial mitigation. LeakCanary should never be active in production builds released to users.
    • Private Storage: Store heap dumps only in the application's private internal storage (e.g., context.getFilesDir()). Do not use external storage.
    • Encryption at Rest: Encrypt the HPROF files after they are created. This requires custom implementation, as LeakCanary doesn't provide this natively. Use a strong encryption algorithm (e.g., AES-256) and securely manage the encryption key.
    • Immediate Deletion: Delete HPROF files as soon as they are no longer needed (after analysis and reporting). Implement a background task to periodically clean up old files.
    • Secure Key Management: If encrypting, use Android's Keystore system to securely store the encryption key. Avoid hardcoding keys.
    • Minimize Sensitive Data in Memory: Practice good memory management. Avoid holding sensitive data in memory for longer than necessary. Use char[] instead of String for sensitive data and overwrite the char[] with zeros after use.

Attack Surface: Leak Report Data Exposure

  • Description: Although less detailed than full heap dumps, leak reports generated by LeakCanary can still expose sensitive information if they are intercepted or accessed without authorization. This includes object references and stack traces that might contain snippets of sensitive data or reveal internal application logic.
  • How LeakCanary Contributes: LeakCanary creates these reports to summarize detected leaks and provide debugging information, making them a direct source of this risk.
  • Example: An attacker uses a network sniffing tool to intercept the leak reports being sent from the device to a remote server. Because the reports are transmitted over an unencrypted connection (HTTP), the attacker can read the contents, potentially revealing details about the application's internal workings or even small pieces of sensitive data.
  • Impact: Breach of confidentiality, potentially exposing parts of sensitive data or revealing internal application structure.
  • Risk Severity: High (While generally less severe than a full heap dump compromise, the risk is still significant due to the potential for revealing sensitive information or aiding in further attacks).
  • Mitigation Strategies:
    • Secure Transport (HTTPS): If reports are sent to a remote server, always use HTTPS with proper certificate validation. Do not use insecure protocols like HTTP.
    • Authenticated Reporting: Implement authentication and authorization for the reporting service to prevent unauthorized access to reports.
    • Data Sanitization/Redaction: Before sending reports, sanitize or redact potentially sensitive information from stack traces or object references. This is a trade-off between debugging utility and security.
    • Local Storage Security: If reports are stored locally, apply the same security measures as for heap dumps (private storage, encryption, short retention).