Skip to content

Latest commit

 

History

History
182 lines (125 loc) · 16.5 KB

mitigations.md

File metadata and controls

182 lines (125 loc) · 16.5 KB

Mitigation Strategies Analysis for square/moshi

Mitigation Strategy: Careful use of lenient() mode

  • Mitigation Strategy: Avoid using Moshi's lenient() mode unless absolutely necessary.

    • Description:

      1. Review existing lenient() usage: Identify all places in the codebase where Moshi.Builder().lenient() is used.
      2. Evaluate necessity: For each usage, determine if lenient() mode is truly required for compatibility with legitimate JSON sources.
      3. Remove lenient() if possible: If lenient() is not essential, remove it to enforce strict JSON parsing.
      4. If lenient() is necessary, add extra validation: If lenient() is required, implement additional validation steps after Moshi parsing to handle potential malformed or unexpected data that lenient() might allow.

    • Threats Mitigated:

      • Deserialization of malformed JSON leading to unexpected behavior (Medium Severity): Prevents parsing of non-standard JSON that could bypass validation or cause issues in application logic.
      • Potential bypass of input validation (Low to Medium Severity): lenient() mode might allow parsing of JSON that would otherwise be rejected by stricter parsers, potentially bypassing intended validation.

    • Impact:

      • Deserialization of malformed JSON leading to unexpected behavior: Medium reduction in risk.
      • Potential bypass of input validation: Low to Medium reduction in risk.

    • Currently Implemented: lenient() mode is not used globally. However, it might be used in specific, older parts of the LegacyIntegrationService for compatibility with external systems.

    • Missing Implementation: A thorough review of LegacyIntegrationService is needed to assess and potentially remove or mitigate the use of lenient() mode. If removal is not possible, additional validation logic must be implemented for data received from leniently parsed JSON.

Mitigation Strategy: Explicitly handle unknown properties

  • Mitigation Strategy: Explicitly handle unknown properties instead of relying on default Moshi behavior.

    • Description:

      1. Choose a handling strategy: Decide how to handle unknown properties:
        • Ignore (with @JsonClass(ignoreUnknown = true)): Explicitly ignore unknown properties using the annotation. Use with caution.
        • Log warnings: Log warnings when unknown properties are encountered.
        • Throw exceptions: Throw exceptions when unknown properties are encountered to enforce strict schema adherence.
        • Custom handling: Implement custom logic in adapters to process or reject unknown properties based on specific requirements.
      2. Implement chosen strategy: Apply the chosen strategy in your Moshi configuration or custom adapters. For @JsonClass(ignoreUnknown = true), annotate relevant data classes. For other strategies, implement custom adapter logic or interceptors.

    • Threats Mitigated:

      • Ignoring malicious or unexpected data (Medium Severity): Prevents silently ignoring potentially malicious or unexpected data embedded in JSON payloads as unknown properties.
      • Data integrity issues (Low Severity): Ensures that all data in the JSON is accounted for and processed, improving data integrity.

    • Impact:

      • Ignoring malicious or unexpected data: Medium reduction in risk.
      • Data integrity issues: Low reduction in risk.

    • Currently Implemented: Default Moshi behavior (ignoring unknown properties without explicit handling) is currently in place across most services.

    • Missing Implementation: A consistent strategy for handling unknown properties needs to be implemented. For critical services like UserService and OrderService, throwing exceptions or logging warnings for unknown properties would be a more secure approach than silently ignoring them. Consider using @JsonClass(ignoreUnknown = true) only for specific data classes where ignoring unknown properties is explicitly intended and safe.

Mitigation Strategy: Use @JsonQualifier for specific property handling

  • Mitigation Strategy: Utilize @JsonQualifier for specific property handling and validation.

    • Description:

      1. Define @JsonQualifier annotations: Create custom annotations (using @Retention(AnnotationRetention.RUNTIME) and @Target(AnnotationTarget.FUNCTION, AnnotationTarget.VALUE_PARAMETER, AnnotationTarget.FIELD)) to represent specific property handling requirements (e.g., @SanitizedString, @Encrypted).
      2. Create custom adapters with qualifiers: Implement custom Moshi adapters that are annotated with these @JsonQualifier annotations. These adapters will handle properties marked with the qualifiers in a specific way (e.g., sanitizing strings, decrypting data).
      3. Annotate data class properties: Annotate properties in your data classes with the defined @JsonQualifier annotations to indicate that they should be processed by the custom qualified adapters.

    • Threats Mitigated:

      • Data injection vulnerabilities (Medium Severity): Allows for targeted sanitization or validation of specific properties, reducing the risk of injection attacks through those properties.
      • Exposure of sensitive data (Medium Severity): Enables specific handling of sensitive properties, such as decryption or masking, reducing the risk of data exposure during serialization.

    • Impact:

      • Data injection vulnerabilities: Medium reduction in risk for targeted properties.
      • Exposure of sensitive data: Medium reduction in risk for targeted properties.

    • Currently Implemented: Not implemented in any service.

    • Missing Implementation: @JsonQualifier can be implemented for sensitive properties in UserService (e.g., email, username) to enforce sanitization or validation during deserialization. It can also be used in OrderService for properties that require specific handling, like encrypted payment information (if applicable).

Mitigation Strategy: Use @Transient or @Json(ignore = true) for sensitive fields

  • Mitigation Strategy: Explicitly annotate sensitive fields with @Transient or @Json(ignore = true).

    • Description:

      1. Identify sensitive fields: Review your data classes/POJOs and identify fields that contain sensitive information (e.g., passwords, API keys, internal IDs, security tokens).
      2. Annotate sensitive fields:
        • Java: Use the @Transient annotation on sensitive fields in Java POJOs.
        • Kotlin: Use the @Json(ignore = true) annotation on sensitive fields in Kotlin data classes when using Moshi.
      3. Verify serialization behavior: Ensure that these annotated fields are not included in JSON output when serializing objects of these data classes/POJOs using Moshi.

    • Threats Mitigated:

      • Exposure of sensitive data in JSON responses (High Severity): Prevents accidental or intentional serialization of sensitive information in API responses or logs.

    • Impact:

      • Exposure of sensitive data in JSON responses: High reduction in risk.

    • Currently Implemented: Partially implemented in UserService. Password fields are marked as @Transient.

    • Missing Implementation: A comprehensive review of all data classes/POJOs across all services is needed to identify and annotate all sensitive fields. This should be a standard practice for all new data models. Specifically, check OrderService and ProductService for any potentially sensitive internal IDs or configuration data that should not be serialized.

Mitigation Strategy: Define explicit serialization adapters for sensitive data

  • Mitigation Strategy: Create custom serialization adapters for sensitive data when serialization is necessary.

    • Description:

      1. Identify sensitive data requiring serialization: Determine cases where sensitive data must be included in JSON output (e.g., for specific API responses or internal communication).
      2. Create custom serialization adapters: Implement custom Moshi adapters specifically for these data types.
      3. Implement secure serialization logic: In the custom adapters, implement secure serialization logic:
        • Masking: Replace sensitive parts of the data with placeholders (e.g., asterisks).
        • Encryption: Encrypt the sensitive data before serialization.
        • Transformation: Transform the data into a less sensitive representation.
      4. Register custom adapters with Moshi: Register these custom adapters with your Moshi instance to ensure they are used for serialization of the relevant data types.

    • Threats Mitigated:

      • Exposure of sensitive data in JSON responses (Medium to High Severity): Reduces the risk of exposing sensitive data even when serialization is required, by masking, encrypting, or transforming the data.

    • Impact:

      • Exposure of sensitive data in JSON responses: Medium to High reduction in risk, depending on the chosen secure serialization method (encryption provides higher reduction than masking).

    • Currently Implemented: Not implemented in any service.

    • Missing Implementation: Consider implementing custom serialization adapters for sensitive data in UserService (e.g., for user profiles where some data might need to be masked) and OrderService (e.g., for displaying masked payment information in order summaries).

Mitigation Strategy: Review default serialization behavior

  • Mitigation Strategy: Understand and review Moshi's default serialization behavior.

    • Description:

      1. Study Moshi documentation: Thoroughly review Moshi's documentation to understand its default serialization behavior for different data types (primitive types, objects, collections, dates, etc.).
      2. Test default serialization: Experiment with serializing various data structures using Moshi's default settings to observe the output and identify any potential security implications.
      3. Adjust serialization if needed: If the default behavior is not secure or exposes more information than desired, implement custom adapters or configurations to override the default behavior and achieve secure serialization.

    • Threats Mitigated:

      • Unintentional exposure of internal data structures (Low to Medium Severity): Prevents accidentally exposing internal object structures or implementation details in JSON responses due to unexpected default serialization behavior.
      • Information leakage (Low Severity): Reduces the risk of information leakage through overly verbose or detailed JSON responses.

    • Impact:

      • Unintentional exposure of internal data structures: Low to Medium reduction in risk.
      • Information leakage: Low reduction in risk.

    • Currently Implemented: No formal review has been conducted. Developers generally rely on default Moshi behavior.

    • Missing Implementation: A security review focused on Moshi's default serialization behavior should be conducted across all services. This review should identify any potential information leakage or unintended data exposure and recommend necessary adjustments (e.g., custom adapters, annotations).

Mitigation Strategy: Review custom adapter code for vulnerabilities

  • Mitigation Strategy: Review custom adapter code for potential vulnerabilities.

    • Description:

      1. Identify custom adapters: Locate all custom Moshi adapters implemented in your project.
      2. Code review: Conduct thorough code reviews of custom adapter implementations, focusing on security aspects:
        • Input validation: Ensure adapters properly validate input data before processing.
        • Error handling: Check for robust error handling to prevent exceptions from leaking sensitive information or causing unexpected behavior.
        • Data sanitization: If adapters handle user-provided data, ensure proper sanitization to prevent injection vulnerabilities.
        • Secure data handling: Verify that adapters handle sensitive data securely (e.g., avoid logging sensitive data, use secure storage if necessary).
      3. Static analysis: Use static analysis tools to scan custom adapter code for potential vulnerabilities (e.g., code injection, insecure data handling).

    • Threats Mitigated:

      • Vulnerabilities introduced by custom adapter logic (Medium to High Severity): Prevents introducing new vulnerabilities through poorly written or insecure custom adapter code.

    • Impact:

      • Vulnerabilities introduced by custom adapter logic: Medium to High reduction in risk, depending on the nature of the vulnerabilities in custom adapters.

    • Currently Implemented: Code reviews are conducted for all code changes, including custom adapters, but security-focused reviews specifically for adapter code are not consistently performed.

    • Missing Implementation: Implement security-focused code reviews specifically for custom Moshi adapters. Include security checklists and guidelines for adapter development in code review processes. Integrate static analysis tools into the CI/CD pipeline to automatically scan adapter code for vulnerabilities.

Mitigation Strategy: Test custom adapters rigorously

  • Mitigation Strategy: Implement unit tests and integration tests specifically for custom Moshi adapters.

    • Description:

      1. Write unit tests: Create unit tests for each custom Moshi adapter to verify its correctness and security in isolation. Test various input scenarios, including:
        • Valid inputs: Test with valid JSON data to ensure correct parsing and serialization.
        • Invalid inputs: Test with malformed or unexpected JSON data to verify proper error handling and resilience.
        • Edge cases: Test with boundary conditions and edge cases to identify potential issues.
        • Malicious inputs: Test with potentially malicious JSON payloads to ensure adapters handle them safely and do not introduce vulnerabilities.
      2. Write integration tests: Implement integration tests that test the interaction of custom adapters within the application context. Verify that adapters work correctly with other components and data flows.
      3. Automate testing: Integrate these tests into your CI/CD pipeline to ensure they are run automatically with every code change.

    • Threats Mitigated:

      • Bugs and errors in custom adapter logic (Medium Severity): Detects functional errors and bugs in custom adapter implementations that could lead to unexpected behavior or vulnerabilities.
      • Security vulnerabilities in custom adapters (Medium to High Severity): Helps identify potential security vulnerabilities in custom adapters through testing with malicious inputs and edge cases.

    • Impact:

      • Bugs and errors in custom adapter logic: Medium reduction in risk.
      • Security vulnerabilities in custom adapters: Medium to High reduction in risk.

    • Currently Implemented: Unit tests are written for some custom adapters, but test coverage is not comprehensive, and security-focused testing is not consistently performed. Integration tests for adapters are limited.

    • Missing Implementation: Improve unit test coverage for all custom adapters, specifically focusing on security testing (malicious inputs, edge cases). Implement integration tests to verify adapter behavior within the application. Make test execution a mandatory part of the CI/CD pipeline.