Skip to content

Latest commit

 

History

History
165 lines (129 loc) · 14.4 KB

mitigations.md

File metadata and controls

165 lines (129 loc) · 14.4 KB

Mitigation Strategies Analysis for facebook/react-native

Mitigation Strategy: Secure WebView Usage (React Native Component)

Mitigation Strategy: Secure WebView Configuration and Communication

  1. Minimize WebView Use: If possible, avoid using the React Native WebView component altogether. Consider using native components or libraries designed for secure rendering of external content. This is the best mitigation, as WebView introduces a large attack surface.
  2. originWhitelist (React Native Prop): If WebView is necessary, use the originWhitelist prop provided by React Native to restrict which origins can be loaded. Only allow trusted domains. Example: originWhitelist={['https://www.example.com']}. This is a React Native-specific control.
  3. Avoid injectJavaScript (React Native API): Minimize the use of the injectJavaScript prop of the React Native WebView. If you must use it, ensure the injected code is:
    • Extremely minimal.
    • Thoroughly reviewed for security vulnerabilities.
    • Does not handle any sensitive data.
  4. postMessage for Communication (React Native API): Use postMessage (from the injected JavaScript) and the onMessage prop (on the React Native WebView component) for communication between the WebView and React Native. This is a more secure way to exchange data than direct JavaScript injection, and it's facilitated by React Native's API.
  5. Validate Messages (React Native Side): Thoroughly validate all messages received from the WebView via the onMessage event handler in your React Native code. Treat these messages as untrusted input. This is crucial for securing the React Native side of the communication.
  6. Disable JavaScript (If Possible - React Native Prop): If the WebView content does not require JavaScript, disable it using the javaScriptEnabled prop of the React Native WebView (set to false). This significantly reduces the attack surface.

Threats Mitigated:

  • Cross-Site Scripting (XSS) (High Severity): Limits the ability of attackers to inject malicious scripts into the WebView and, crucially, prevents those scripts from interacting with the React Native application in unintended ways.
  • Code Injection (High Severity): Reduces the risk of attackers injecting arbitrary code through the WebView that could then interact with the React Native bridge.
  • Data Exfiltration (High Severity): Limits the ability of malicious code within the WebView to access sensitive data in the React Native application via the bridge.
  • Phishing (Medium Severity): Makes it more difficult for attackers to load phishing pages within the WebView and trick users into providing credentials that could be sent to the React Native side.

Impact:

  • XSS: Significantly reduces the risk, especially when combined with CSP (though CSP itself isn't React Native-specific).
  • Code Injection: Significantly reduces the risk.
  • Data Exfiltration: Significantly reduces the risk.
  • Phishing: Reduces the risk.

Currently Implemented:

  • originWhitelist is used in src/components/HelpScreen.js to restrict the WebView to the official documentation website.
  • postMessage is used for communication in src/components/HelpScreen.js.

Missing Implementation:

  • Message validation is basic and needs to be strengthened in src/components/HelpScreen.js. A more robust schema should be used, specifically within the React Native onMessage handler.
  • javaScriptEnabled is not explicitly set to false where possible.

Mitigation Strategy: Secure Storage of Sensitive Data (Using React Native Libraries)

Mitigation Strategy: Use Native Secure Storage APIs via React Native Libraries

  1. Identify Sensitive Data: Identify all sensitive data.
  2. Choose a Secure Storage React Native Library: Select a React Native library that provides access to platform-specific secure storage mechanisms. This is the key React Native-specific part:
    • Examples: react-native-keychain, react-native-sensitive-info. These libraries bridge the gap to native secure storage.
  3. Implement Secure Storage (Using the Library): Use the chosen React Native library to store and retrieve sensitive data. Follow the library's documentation carefully. The library handles the interaction with the native APIs.
  4. Data Minimization: Only store the minimum amount of sensitive data required. Delete data when it is no longer needed.
  5. Access Control: Implement appropriate access controls within your React Native code to ensure that only authorized parts of your application can access the stored data (using the library's API).

Threats Mitigated:

  • Data Breach (High Severity): Protects sensitive data from being accessed, even if the device is compromised, by leveraging native secure storage through the React Native library.
  • Reverse Engineering (Medium Severity): Makes it more difficult for attackers to extract sensitive data by reverse engineering the React Native application, as the data is not stored in plain text within the JavaScript bundle.
  • Code Injection (High Severity): Even if an attacker injects code into the React Native JavaScript environment, they won't be able to directly access data stored in secure storage (accessed via the native bridge).

Impact:

  • Data Breach: Significantly reduces the risk.
  • Reverse Engineering: Significantly reduces the risk.
  • Code Injection: Reduces the impact of code injection.

Currently Implemented:

  • react-native-keychain is used to store authentication tokens in src/services/AuthService.js.

Missing Implementation:

  • No secure storage is used for user preferences that might contain PII (e.g., location data). A React Native secure storage library needs to be used here.

Mitigation Strategy: Secure Deep Link Handling (React Native Navigation and Linking)

Mitigation Strategy: Validate and Restrict Deep Link Actions using React Native APIs

  1. Identify Deep Link Schemes: Identify all deep link schemes your application handles, as configured for your React Native project.
  2. Validate Deep Link URLs (React Native Side): Implement strict validation for all deep link URLs received by your application using React Native's Linking API. This validation should happen within your React Native code. Check:
    • Scheme: Ensure the scheme matches your expected schemes.
    • Host: Ensure the host is valid (if applicable).
    • Path: Validate the path and ensure it conforms to expected patterns.
    • Query Parameters: Validate all query parameters, including their types, formats, and values. This is all done within the React Native Linking.addEventListener handler.
  3. Avoid Sensitive Actions: Do not perform sensitive actions directly from deep links without additional authentication or confirmation within your React Native application.
  4. App Links (Android) and Universal Links (iOS): While the configuration of these is platform-specific, the handling of the resulting links is done within React Native, typically using the Linking API.
  5. Testing: Thoroughly test your deep link handling within your React Native application, including edge cases and invalid URLs.

Threats Mitigated:

  • Deep Link Hijacking (Medium Severity): Prevents other applications from intercepting and handling your application's deep links (especially when combined with App Links/Universal Links).
  • Unauthorized Actions (High Severity): Prevents attackers from using deep links to trigger unauthorized actions within your React Native application.
  • Data Exfiltration (Medium Severity): Reduces the risk of attackers using deep links to extract sensitive data from your React Native application.
  • Phishing (Medium Severity): Makes it more difficult to use deep links for phishing attacks.

Impact:

  • Deep Link Hijacking: Significantly reduces the risk.
  • Unauthorized Actions: Significantly reduces the risk.
  • Data Exfiltration: Reduces the risk.
  • Phishing: Reduces the risk.

Currently Implemented:

  • Basic deep link handling is implemented in src/navigation/AppNavigator.js using React Native's Linking API.

Missing Implementation:

  • Deep link URLs are not thoroughly validated within the React Native code. Strict validation rules need to be added to the Linking.addEventListener handler.
  • Sensitive actions (like password reset) can be triggered via deep links without additional authentication within the React Native app. This needs to be changed.

Mitigation Strategy: Secure Bridge Communication (JavaScript to Native and Vice-Versa)

Mitigation Strategy: Strict Validation and Type Checking for Bridge Communication

  1. Identify Bridge Communication Points: List all points where data is passed between JavaScript and native code using the React Native bridge. This includes:
    • Calls to native modules from JavaScript.
    • Events emitted from native modules to JavaScript.
    • Any custom bridging mechanisms.
  2. Define a Schema: Create a well-defined schema for all data passed across the bridge. This schema should specify:
    • The expected data types (string, number, boolean, array, object).
    • The structure of objects (required properties, allowed values).
    • Any constraints on the data (e.g., minimum/maximum lengths, regular expressions).
  3. Implement Validation (JavaScript Side): Before sending data to a native module, validate it against the defined schema in your React Native JavaScript code.
  4. Implement Validation (Native Side): When receiving data from JavaScript, validate it against the defined schema in your native code (Objective-C/Swift or Java/Kotlin). Do not assume the JavaScript side has performed validation.
  5. Type Checking: Use strict type checking on both sides of the bridge. Avoid using dynamic types or any types where possible.
  6. Error Handling: Implement robust error handling for bridge communication. If validation fails, return a clear error message to the other side of the bridge.
  7. Serialization: Use a well-defined serialization format like JSON for bridge communication.

Threats Mitigated:

  • Bridge Injection (High Severity): Prevents malicious data from being passed from JavaScript to native code (or vice-versa), potentially exploiting vulnerabilities in native components or causing crashes. This is specific to the React Native bridge.
  • Data Corruption (Medium Severity): Prevents invalid or unexpected data from corrupting application state on either side of the bridge.
  • Code Injection (High Severity): Reduces the risk of code injection vulnerabilities that could be triggered by passing malicious data to native code.

Impact:

  • Bridge Injection: Significantly reduces the risk.
  • Data Corruption: Reduces the risk.
  • Code Injection: Reduces the risk.

Currently Implemented:

  • Basic type checking is performed in src/nativeModules/MyNativeModule.js (JavaScript side) before calling native methods.

Missing Implementation:

  • A formal schema for bridge communication is not defined. This needs to be created.
  • Validation is not consistently implemented on the native side (in the corresponding Objective-C/Java code). This is a critical gap.
  • Robust error handling for bridge communication is missing.

Mitigation Strategy: Secure OTA Updates (Using React Native Specific Services)

Mitigation Strategy: Secure OTA Update Mechanism with Code Signing (using React Native-focused services)

  1. Choose a Secure OTA React Native Service: If using an OTA update service, choose one that is specifically designed for React Native and prioritizes security. Examples include:
    • CodePush (Microsoft App Center): A popular choice, but requires careful configuration.
    • Other React Native-focused OTA services: Research alternatives that may offer stronger security features.
  2. Code Signing (React Native Build Process): Sign your OTA updates using a private key. The public key should be embedded in your React Native application (typically during the build process) to verify the signature before applying the update. This is integrated into the React Native build and deployment workflow.
  3. Rollback Mechanism: Implement a mechanism to revert to a previous version of your React Native application if an OTA update introduces issues.
  4. Update Verification (React Native Runtime): Before applying an update, verify:
    • The digital signature (using the embedded public key).
    • The update's integrity.
    • That the update is intended for your application. This verification happens within the React Native runtime.
  5. User Consent: Consider prompting the user for consent before downloading and installing an OTA update.

Threats Mitigated:

  • Man-in-the-Middle (MitM) Attacks (High Severity): Prevents attackers from intercepting and modifying OTA updates delivered to the React Native application.
  • Malicious Updates (High Severity): Prevents attackers from distributing malicious updates to your React Native application.
  • Update Rollback Failure (Medium Severity): Ensures that you can revert to a previous version of your React Native app if an update causes problems.

Impact:

  • MitM Attacks: Significantly reduces the risk.
  • Malicious Updates: Significantly reduces the risk.
  • Update Rollback Failure: Reduces the risk.

Currently Implemented:

  • CodePush is used for OTA updates.
  • HTTPS is used for CodePush communication (this is a general best practice, but CodePush handles it).

Missing Implementation:

  • Code signing is not currently implemented for CodePush updates. This is a critical missing security feature, and it needs to be integrated into the React Native build process.
  • Update verification beyond basic HTTPS checks is not performed within the React Native runtime.