Skip to content

Latest commit

 

History

History
109 lines (84 loc) · 6.63 KB

mitigations.md

File metadata and controls

109 lines (84 loc) · 6.63 KB

Mitigation Strategies Analysis for apache/commons-lang

Mitigation Strategy: Avoid Deserialization of Untrusted Data / Implement Strict Whitelisting (Specifically targeting SerializationUtils)

  • Description:

    1. Identify all uses of SerializationUtils.deserialize() within the codebase. Use code search tools.
    2. Analyze the source of the data. Is it trusted (internal, digitally signed) or untrusted (user input, external API)?
    3. If untrusted, eliminate deserialization if possible. Use JSON, XML with strict schema validation, or other safer alternatives.
    4. If absolutely unavoidable (rare!), implement a strict whitelist using ObjectInputFilter (Java 9+):
      • Create an ObjectInputFilter: ObjectInputFilter.Config.createFilter("com.myapp.SafeClass1;com.myapp.SafeClass2;!*"). This allows only listed classes, rejecting everything else.
      • Create an ObjectInputStream wrapping the input stream.
      • Set the filter: ois.setObjectInputFilter(filter).
      • Use SerializationUtils.deserialize(ois) with the filtered stream.
    5. Thoroughly test with valid and malicious serialized data.
    6. Document whitelisted classes and rationale.

  • List of Threats Mitigated:

    • Remote Code Execution (RCE) (Critical): Malicious serialized objects can execute arbitrary code.
    • Denial of Service (DoS) (High): Crafted data can cause resource exhaustion.
    • Data Tampering (High): Unexpected object manipulation.

  • Impact:

    • RCE: Risk reduced from Critical to Very Low (whitelist) or Eliminated (avoidance).
    • DoS: Risk reduced from High to Low.
    • Data Tampering: Risk reduced from High to Low.

  • Currently Implemented: [Placeholder: e.g., "Implemented in com.myapp.services.DataImportService using ObjectInputFilter."]

  • Missing Implementation: [Placeholder: e.g., "Missing in com.myapp.legacy.OldDataProcessor."]

Mitigation Strategy: Migrate to commons-text and Use Context-Specific Escaping (Addressing StringEscapeUtils deprecation)

  • Description:

    1. Find all uses of org.apache.commons.lang.StringEscapeUtils (deprecated).
    2. Replace with org.apache.commons.text.StringEscapeUtils methods. e.g., StringEscapeUtils.escapeHtml4() becomes StringEscapeUtils.escapeHtml4().
    3. Ensure the correct escaping method is used for the output context:
      • HTML: escapeHtml4(), escapeHtml3()
      • XML: escapeXml10(), escapeXml11()
      • JavaScript: escapeEcmaScript()
      • CSV: escapeCsv()
      • Never mix escaping methods.
    4. Verify output is properly encoded (e.g., charset=UTF-8 for HTML).
    5. Implement input validation before escaping.
    6. Test with special characters and XSS payloads.

  • List of Threats Mitigated:

    • Cross-Site Scripting (XSS) (High): Inject malicious JavaScript.
    • XML Injection (High): Manipulate XML structure.
    • JavaScript Injection (High): Execute arbitrary JavaScript.
    • CSV Injection (Medium): Data corruption in CSV.

  • Impact:

    • XSS, XML, JavaScript Injection: Risk reduced from High to Low.
    • CSV Injection: Risk reduced from Medium to Low.

  • Currently Implemented: [Placeholder: e.g., "Migrated to commons-text. Context-specific escaping used in templates and API responses."]

  • Missing Implementation: [Placeholder: e.g., "Legacy reporting module uses old StringEscapeUtils."]

Mitigation Strategy: Ensure Cryptographically Secure Random Number Generation (with RandomStringUtils)

  • Description:

    1. Identify uses of RandomStringUtils for security (passwords, tokens, keys).
    2. Explicitly provide a SecureRandom instance: 
      SecureRandom secureRandom = new SecureRandom();
String randomString = RandomStringUtils.random(..., secureRandom);
    3. For highly sensitive operations (long-term keys), use dedicated cryptographic APIs (e.g., KeyPairGenerator, KeyGenerator).
    4. Ensure SecureRandom is properly seeded (usually handled by the OS).
    5. Test randomness statistically if required by security policy.

  • List of Threats Mitigated:

    • Session Hijacking (High): Predictable tokens.
    • Password Cracking (High): Weak passwords.
    • Cryptographic Key Compromise (Critical): Predictable keys.

  • Impact:

    • Session Hijacking, Password Cracking, Key Compromise: Risk reduced from High/Critical to Low.

  • Currently Implemented: [Placeholder: e.g., "RandomStringUtils uses SecureRandom explicitly."]

  • Missing Implementation: [Placeholder: e.g., "Password reset tokens use default RandomStringUtils."]

Mitigation Strategy: Layered Input Validation with Validate (Using Validate Correctly)

  • Description:

    1. Identify all uses of the Validate class.
    2. Analyze the validation and input type.
    3. Supplement Validate with more specific checks:
      • Regular Expressions: Enforce formats (email, username, phone).
      • Type-Specific Validation: Min/max values, integer-only.
      • Custom Logic: For complex data or business rules.
    4. Validate early ("fail fast").
    5. Test with valid and invalid inputs, including boundary cases and attacks.

  • List of Threats Mitigated:

    • Injection Attacks (SQLi, Command Injection) (High): Prevent malicious characters.
    • Data Corruption (Medium): Validate types and formats.
    • Logic Errors (Medium): Prevent unexpected behavior.

  • Impact:

    • Injection Attacks: Risk reduced from High to Low (with other mitigations).
    • Data Corruption, Logic Errors: Risk reduced from Medium to Low.

  • Currently Implemented: [Placeholder: e.g., "Validate used, but often without additional checks. Regexes used inconsistently."]

  • Missing Implementation: [Placeholder: e.g., "User profile updates rely on Validate.notEmpty() only. Needs regex validation."]