mitigations.md

Mitigation Strategies Analysis for php-fig/container

Mitigation Strategy: Principle of Least Privilege (Container Configuration)

*   **Mitigation Strategy:** Enforce strict access control within the container configuration.

*   **Description:**
    1.  **Explicit Service Definitions:**  In your container configuration file (e.g., `config/container.php`, `services.yaml`), define *each* service individually.  Avoid auto-discovery or auto-wiring unless absolutely necessary and thoroughly secured.  Explicitly define dependencies using constructor injection or setter injection within the container configuration.
    2.  **Restricted Service Access (Configuration Level):**  If your container implementation supports it, use features that restrict which parts of your application can access specific services.  This might involve tagging services or using separate container instances for different modules.  The goal is to prevent a component from requesting a service it shouldn't have access to *at the container level*.
    3.  **Factory-Based Instantiation:**  Use factories (closures or dedicated factory classes) to create service instances.  Within the factory, you can:
        *   Validate constructor arguments.
        *   Enforce specific object configurations.
        *   Prevent direct instantiation of sensitive classes.
        *   Log service creation.
    4.  **Avoid Dynamic Service Names:**  Never, under any circumstances, allow user input or untrusted data to directly determine the service name requested from the container (`$container->get($userInput)` is a critical vulnerability).  Use a whitelist or a mapping approach if you need to map user input to service names, and define these mappings *within the container configuration*.

*   **List of Threats Mitigated:**
    *   **Overly Permissive Access (Severity: High):**  Reduces the impact of a compromised component by limiting its access to other services.
    *   **Dependency Injection Attacks (Severity: High):** Prevents attackers from injecting malicious services by manipulating service names.
    *   **Information Disclosure (Severity: Medium):**  Limits the potential for leaking information about available services.

*   **Impact:**
    *   **Overly Permissive Access:**  Significantly reduces the attack surface.
    *   **Dependency Injection Attacks:**  Effectively eliminates the risk of direct service name injection.
    *   **Information Disclosure:**  Reduces the amount of information exposed.

*   **Currently Implemented:**
    *   Explicit service definitions are partially implemented in `config/services.php`.
    *   Factory-based instantiation is used for the `DatabaseConnection` service.
    *   Dynamic service names are *not* currently protected against.

*   **Missing Implementation:**
    *   Review and refactor all service definitions to be explicit.
    *   Investigate container-level access restriction features (if supported by the chosen implementation).
    *   Implement a whitelist or mapping for *all* cases where user input might influence service retrieval, ensuring this is done *within the container configuration*.

Mitigation Strategy: Dependency Injection (DI) Container Poisoning

*   **Mitigation Strategy:** Prevent unauthorized modification of the container's configuration.

*   **Description:**
    1.  **Immutable Configuration:**  After the application initializes and the container is built, the container configuration (service definitions, aliases, etc.) should be treated as completely read-only.  Do *not* provide any API or mechanism to add, remove, or modify service definitions at runtime.  This is a crucial step to prevent attackers from injecting malicious services.
    2. **Separate Configuration by Environment:** Use separate configuration files for different environments (development, testing, production). Ensure that production configuration is loaded only in production environment.

*   **List of Threats Mitigated:**
    *   **Container Configuration Tampering (Severity: Critical):** Prevents attackers from injecting malicious services or modifying existing ones *after* the application has started.
    *   **Privilege Escalation (Severity: High):**  Limits the ability of an attacker to gain control by modifying the container.

*   **Impact:**
    *   **Container Configuration Tampering:**  Significantly reduces the risk of successful container poisoning.
    *   **Privilege Escalation:** Makes it much harder to escalate privileges via the container.

*   **Currently Implemented:**
    *   Separate configuration files for different environments are implemented (`config/`).

*   **Missing Implementation:**
    *   The container configuration is *not* strictly immutable after initialization.  This requires a code review and refactoring to ensure no runtime modifications are possible.

Mitigation Strategy: Service Impersonation/Substitution

*   **Mitigation Strategy:** Enforce type safety and explicit service definitions *within the container*.

*   **Description:**
    1.  **Explicit Service Aliases (with Caution):** If you use service aliases, define them *explicitly* in the container configuration.  Avoid using aliases that are easily guessable or could be derived from user input.  Treat aliases with the same security considerations as the primary service names.  The container configuration is the *only* place aliases should be defined.
    2. **Always use `get()` after `has()`:** Ensure that you always retrieve the service using `get()` after checking its existence with `has()`.

*   **List of Threats Mitigated:**
    *   **Service Impersonation (Severity: High):**  Makes it harder to replace a legitimate service with a malicious one, especially if combined with type hinting in the consuming code.
    *   **Type Confusion Attacks (Severity: Medium):**  Reduces the risk, although type hinting in the application code is the primary defense here.

*   **Impact:**
    *   **Service Impersonation:**  Reduces the likelihood of successful impersonation.
    *   **Type Confusion Attacks:**  Provides some protection, but relies on application-level type hinting.

*   **Currently Implemented:**
    *   Explicit service aliases are used in some parts of the configuration.

*   **Missing Implementation:**
    *   Review all alias definitions to ensure they are secure and not predictable.
    *   Ensure consistent use of `get()` after `has()`.

Mitigation Strategy: Denial of Service (DoS) via Container

*   **Mitigation Strategy:** Optimize service creation and resource usage *within the container configuration*.

*   **Description:**
    1.  **Lazy Loading:**  Configure services to be loaded lazily (only when they are actually needed).  This is a configuration option within the container itself (e.g., `lazy: true` in Symfony, or often the default behavior in other containers).  This prevents the container from creating all services upfront.
    2.  **Service Instance Sharing (Singletons):**  Configure the container to share service instances whenever possible (singletons).  This is also a container configuration option (often the default, but can be explicitly configured).  This avoids creating multiple instances of the same service, reducing memory usage.  *Crucially*, ensure that shared services are designed to be thread-safe if your application is multi-threaded.

*   **List of Threats Mitigated:**
    *   **Resource Exhaustion (Severity: Medium):**  Reduces the risk of an attacker causing a denial-of-service by triggering excessive service creation.

*   **Impact:**
    *   **Resource Exhaustion:**  Improves the application's resilience to DoS attacks targeting the container.

*   **Currently Implemented:**
    *   Lazy loading is enabled for most services.
    *   Service instance sharing is used for some services (e.g., `DatabaseConnection`).

*   **Missing Implementation:**
    *   Review all service definitions to ensure that lazy loading and sharing are used appropriately and consistently.  Pay close attention to the thread-safety of shared services.

Mitigation Strategy: Information Disclosure (Container Configuration)

• Mitigation Strategy: Prevent the container configuration from directly storing sensitive information.

*   **Description:**
    1.  **Minimal Configuration Exposure:**  Do *not* store sensitive data (database credentials, API keys, secrets) directly within the container configuration files.  The container configuration should *only* contain instructions on *how to retrieve* these secrets, not the secrets themselves.  Use environment variables or a dedicated secrets management solution.  The container configuration should then be set up to read these values from the environment or secrets manager.

*   **List of Threats Mitigated:**
    *   **Information Leakage (Severity: Medium to High):** Prevents sensitive data from being exposed if the container configuration files are compromised.

*   **Impact:**
    *   **Information Leakage:** Significantly reduces the risk of exposing secrets stored in the container configuration.

*   **Currently Implemented:**
    *   Database credentials are *not* stored in the container configuration; they are loaded from environment variables.

*   **Missing Implementation:**
    *   Audit all configuration files and code to ensure that *no* secrets are hardcoded anywhere, including within the container configuration.