Skip to content

Latest commit

 

History

History
62 lines (53 loc) · 5.98 KB

attack-surface.md

File metadata and controls

62 lines (53 loc) · 5.98 KB

Attack Surface Analysis for facebook/facebook-android-sdk

Attack Surface: Access Token Theft via Deep Link Hijacking

  • Description: Attackers exploit misconfigured deep link handling to intercept the Facebook login callback and steal the user's Access Token. This is directly related to the SDK because the SDK dictates the use of deep links for the login flow.
  • Facebook SDK Contribution: The SDK requires the use of deep links as part of its OAuth 2.0 login flow to return the Access Token to the application after successful authentication. The SDK's design choice creates this attack vector.
  • Example: An attacker creates a malicious app with an intent filter that matches the deep link scheme used by the legitimate app. The Facebook SDK redirects to this deep link, and the malicious app intercepts the Access Token.
  • Impact: Complete account takeover on Facebook. The attacker can impersonate the user and access data/perform actions within the granted permission scope.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Developers:
      • Implement robust deep link validation, going beyond standard Android checks. Verify the origin of the intent (difficult, as getCallingActivity() can be spoofed).
      • Use a unique, unpredictable deep link scheme.
      • Strongly consider App Links (Android) or Universal Links (iOS), which provide cryptographic verification of app ownership.
      • Prefer Custom Tabs (Chrome Custom Tabs) for the login flow. This isolates the login process in a secure browser context managed by the system, mitigating many deep link hijacking risks. This is a direct mitigation for an SDK-introduced vulnerability.
      • Implement a nonce or state parameter, passed during the initial login request and verified in the callback. This helps ensure the callback originates from the expected Facebook login flow.
    • Users: Be cautious about installing apps from untrusted sources.

Attack Surface: Insecure Access Token Storage (Direct SDK Interaction)

  • Description: While the application is responsible for storage, the SDK provides the token and influences how it's handled. The attack surface exists because the SDK provides this highly sensitive data.
  • Facebook SDK Contribution: The SDK generates and delivers the Access Token to the application after successful login. The application's handling of this SDK-provided token is the core issue.
  • Example: The application, after receiving the token from the SDK, stores it in plain text in SharedPreferences.
  • Impact: Account takeover on Facebook. The attacker gains control of the user's account within the granted permission scope.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Developers:
      • Use the Android Keystore system. This is the recommended approach for storing cryptographic keys and sensitive data like Access Tokens.
      • Encrypt the Access Token before storing it, even if using a seemingly secure storage mechanism. This adds an extra layer of protection.
      • Never store Access Tokens in logs, URLs, or easily accessible locations.
      • Consider the AccountManager API for managing user accounts and tokens, which offers additional security features.
    • Users: Keep your device secure (strong password, screen lock, up-to-date software).

Attack Surface: Server-Side Access Token Validation Bypass (Indirect, but SDK-Driven)

  • Description: The application's backend server fails to validate the SDK-provided Access Token. While the server is responsible, the need for validation arises directly from the SDK's token-based authentication.
  • Facebook SDK Contribution: The SDK provides the Access Token to the client. The entire authentication model relies on this token, making server-side validation essential due to the SDK's design.
  • Example: An attacker intercepts a valid Access Token and replays it to the server. The server doesn't check the token's validity with Facebook and grants access.
  • Impact: Unauthorized access to user data and functionality on the application's server. The attacker bypasses authentication.
  • Risk Severity: High
  • Mitigation Strategies:
    • Developers:
      • Mandatory Server-Side Validation: Always validate the Access Token with Facebook's Graph API on the server. Verify signature, expiration, and associated user ID. This is a direct response to the SDK's authentication mechanism.
      • Check the token's expiration.
      • Verify the token's App ID.
      • Implement robust error handling for invalid tokens.
    • Users: No direct mitigation (server-side issue).

Attack Surface: Outdated SDK Version

  • Description: Using an outdated version of the Facebook SDK itself exposes the application to known vulnerabilities within the SDK's code.
  • Facebook SDK Contribution: This is a direct vulnerability of the SDK. The outdated code is the SDK.
  • Example: An old SDK version has a known flaw allowing attackers to bypass certain security checks.
  • Impact: Varies depending on the vulnerability, but can range from data breaches to complete account takeover.
  • Risk Severity: High (depending on the specific vulnerability)
  • Mitigation Strategies:
    • Developers:
      • Regularly update the Facebook SDK to the latest version. This is the primary mitigation.
      • Monitor Facebook's developer documentation for security advisories.
      • Implement a process for rapid SDK updates in response to critical vulnerabilities.
    • Users: Keep your apps updated.