Skip to content

Latest commit

 

History

History
124 lines (93 loc) · 10.7 KB

mitigations.md

File metadata and controls

124 lines (93 loc) · 10.7 KB

Mitigation Strategies Analysis for apache/struts

Mitigation Strategy: Strict OGNL Expression Validation (Whitelist Approach)

  • Description:

    1. Identify All OGNL Usages: Thoroughly review all JSPs, action configurations (struts.xml), and any custom tag libraries to identify every instance where OGNL expressions are used. This includes implicit uses (e.g., within <s:property> tags).
    2. Define Allowed Expressions: For each identified OGNL usage, create a precise whitelist of exactly what is allowed. This should be as restrictive as possible. For example, instead of allowing user.address.*, allow only user.address.street, user.address.city, user.address.zip.
    3. Implement Validation:
      • Option A (Preferred): Custom SecurityMemberAccess: Create a custom implementation of the com.opensymphony.xwork2.security.SecurityMemberAccess interface. Override the isAccessible() method to enforce your whitelist. This provides the most granular control. Register this custom implementation in your struts.xml or struts.properties.
      • Option B (Less Preferred, but easier): params Interceptor: Use the params interceptor's excludeParams and allowedMethods parameters to restrict access. This is a blacklist approach, so it's less secure than a whitelist, but it can be a useful starting point. Combine this with Option A for best results.
      • Option C (Least Preferred): Hardcoded Checks: As a last resort, you could add hardcoded checks within your action classes to validate OGNL expressions before they are used. This is error-prone and difficult to maintain.
    4. Testing: Thoroughly test each OGNL usage with both valid and invalid inputs to ensure the whitelist is working correctly. Include negative tests (attempts to access disallowed properties or methods).

  • Threats Mitigated:

    • OGNL Injection (Remote Code Execution - RCE): Severity: Critical. Allows attackers to execute arbitrary code on the server.
    • Data Exposure: Severity: High. Attackers could potentially access sensitive data not intended for display.
    • Privilege Escalation: Severity: High. Attackers might be able to elevate their privileges within the application.

  • Impact:

    • OGNL Injection (RCE): Risk reduced from Critical to Low (with a well-implemented whitelist).
    • Data Exposure: Risk reduced from High to Low.
    • Privilege Escalation: Risk reduced from High to Low.

  • Currently Implemented:

    • Example: params interceptor configured in struts.xml with a basic excludeParams list (blacklist approach). Custom SecurityMemberAccess not implemented. Hardcoded checks in UserAction for specific OGNL expressions.

  • Missing Implementation:

    • Critical: A comprehensive custom SecurityMemberAccess implementation is missing. This is the highest priority.
    • High: The excludeParams list in struts.xml needs to be reviewed and expanded to be more comprehensive (even though it's a blacklist).
    • Medium: Hardcoded checks in action classes should be replaced with the SecurityMemberAccess implementation.
    • Low: A full audit of all OGNL usage points is needed to ensure no expressions are missed.

Mitigation Strategy: Restrict Class Loader Access

  • Description:

    1. Identify Potentially Dangerous Classes/Packages: Create a list of classes and packages that should never be accessible through Struts' class loading mechanisms. This includes classes related to system administration, reflection, networking, and file I/O.
    2. Configure struts.excludedClasses and struts.excludedPackageNames: In your struts.properties or struts.xml file, use these properties to specify the classes and packages to exclude. This is a blacklist approach.
    3. Testing: Attempt to access restricted classes through Struts (e.g., using OGNL expressions) to verify that the restrictions are working.

  • Threats Mitigated:

    • Arbitrary Class Loading (RCE): Severity: Critical. Attackers could instantiate arbitrary classes, potentially leading to remote code execution.
    • Resource Access Violations: Severity: High. Attackers might gain access to files, network resources, or other system resources they shouldn't have access to.

  • Impact:

    • Arbitrary Class Loading (RCE): Risk reduced from Critical to Medium (with a well-maintained blacklist).
    • Resource Access Violations: Risk reduced from High to Medium.

  • Currently Implemented:

    • Example: Basic struts.excludedClasses and struts.excludedPackageNames configuration in struts.properties, but the list is incomplete.

  • Missing Implementation:

    • High: The struts.excludedClasses and struts.excludedPackageNames lists need to be thoroughly reviewed and expanded. This should be an ongoing process as new potential attack vectors are discovered.

Mitigation Strategy: Strict Parameter Filtering (Whitelist Approach)

  • Description:

    1. Identify All Action Methods: List all methods in your action classes that are intended to be invoked by user requests.
    2. Define Allowed Methods: Use the params interceptor's allowedMethods parameter in struts.xml to explicitly list the allowed methods for each action. This is a whitelist approach.
    3. Define Allowed Action Names (if applicable): If you use action names (e.g., in URLs), use the allowedActionNames parameter to restrict which action names are allowed.
    4. Disable Dynamic Method Invocation (DMI): Set struts.enable.DynamicMethodInvocation to false in struts.properties to prevent attackers from invoking arbitrary methods.
    5. Testing: Attempt to invoke disallowed methods or action names through URLs or form submissions to verify the restrictions.

  • Threats Mitigated:

    • Parameter Tampering (Method Invocation): Severity: High. Attackers could invoke unintended methods on your action classes.
    • Dynamic Method Invocation (DMI) Attacks: Severity: High. Attackers could invoke arbitrary methods.

  • Impact:

    • Parameter Tampering (Method Invocation): Risk reduced from High to Low.
    • DMI Attacks: Risk reduced from High to None (if DMI is disabled).

  • Currently Implemented:

    • Example: struts.enable.DynamicMethodInvocation is set to false. allowedMethods is not used. excludeParams is used (blacklist), but not comprehensively.

  • Missing Implementation:

    • Critical: Implement allowedMethods in struts.xml for all actions. This is the most important missing piece.
    • Medium: Review and improve the excludeParams configuration (even though it's a blacklist).

Mitigation Strategy: Sanitize Redirect URLs and Avoid chain Result

  • Description:

    1. Avoid chain: Do not use the chain result type. Use redirectAction or redirect instead.
    2. Identify Redirect Usages: Find all instances where redirect or redirectAction are used.
    3. Validate Redirect Targets:
      • Option A (Preferred): Whitelist: If possible, maintain a whitelist of allowed redirect URLs or URL patterns within your Struts configuration or application logic. Only redirect to URLs that match the whitelist.
      • Option B (Less Preferred): Sanitization: If a whitelist is not feasible, thoroughly sanitize any user-supplied data that is used to construct the redirect URL within your Struts action. Remove or escape any characters that could be used for open redirect attacks (e.g., //, \, etc.). This is less secure than a whitelist.
      • Option C (Avoid): Relative Redirects: Use relative redirects whenever possible. This reduces the attack surface.
    4. Testing: Attempt to inject malicious URLs into redirect parameters to verify that the validation/sanitization is working.

  • Threats Mitigated:

    • Open Redirect: Severity: Medium. Attackers could redirect users to malicious websites.
    • Cross-Site Scripting (XSS) (in some cases): Severity: High. Open redirects can sometimes be used to inject malicious scripts.

  • Impact:

    • Open Redirect: Risk reduced from Medium to Low (with a whitelist) or Medium-Low (with sanitization).
    • XSS: Risk reduced indirectly (by preventing open redirects that could be used for XSS).

  • Currently Implemented:

    • Example: chain result type is not used. Some basic sanitization of redirect URLs is performed, but no whitelist is used.

  • Missing Implementation:

    • High: Implement a whitelist of allowed redirect URLs if feasible, ideally within the Struts configuration.
    • Medium: Improve the sanitization logic to be more robust and comprehensive.

Mitigation Strategy: Keep Struts Updated

  • Description:

    1. Subscribe to Security Announcements: Subscribe to the Apache Struts security mailing list and monitor other security advisories.
    2. Use Dependency Management: Use a tool like Maven or Gradle to manage Struts dependencies.
    3. Regular Updates: Establish a regular schedule for updating Struts to the latest stable version. Apply security patches immediately upon release.
    4. Testing: After updating Struts, thoroughly test the application to ensure that the update did not introduce any regressions.

  • Threats Mitigated:

    • All Known Struts Vulnerabilities: Severity: Varies (from Low to Critical). This mitigates all vulnerabilities that have been publicly disclosed and patched.

  • Impact:

    • All Known Struts Vulnerabilities: Risk reduced significantly (depending on the specific vulnerabilities patched). This is the single most important mitigation.

  • Currently Implemented:

    • Example: Struts is updated periodically, but not immediately upon the release of security patches. Dependency management is used (Maven).

  • Missing Implementation:

    • High: Establish a process for applying security patches immediately upon release.
    • Medium: Improve the testing process after Struts updates to ensure comprehensive regression testing.