Skip to content

Latest commit

 

History

History
141 lines (117 loc) · 12.6 KB

mitigations.md

File metadata and controls

141 lines (117 loc) · 12.6 KB

Mitigation Strategies Analysis for walkor/workerman

Mitigation Strategy: Worker Process Recycling (Workerman Specific)

  • Description:

    1. Implement Worker::$maxEventLoops or Worker::$maxRequests: Utilize Workerman's built-in mechanisms for worker recycling.
      • Worker::$maxEventLoops: Set a limit on the number of event loop iterations a worker process will execute before restarting. This is useful for memory leak mitigation in long-running connections.
      • Worker::$maxRequests: Set a limit on the number of requests a worker process will handle before restarting. This is effective for PHP applications where request handling might lead to resource accumulation.
    2. Configure Recycling in Worker Initialization: Within your Workerman application's main script, configure these properties when initializing your Worker instances. For example: 
      use Workerman\Worker;

$http_worker = new Worker("http://0.0.0.0:8080");
$http_worker->count = 4;
$http_worker->maxRequests = 1000; // Restart after 1000 requests
$http_worker->onMessage = function($connection, $data) {
    $connection->send('hello ' . $data);
};

Worker::runAll();
    3. Choose Appropriate Recycling Strategy: Select either maxEventLoops or maxRequests or a combination based on your application's characteristics and potential resource leak patterns. For long-lived connections (like WebSockets), maxEventLoops might be more relevant. For request-response applications, maxRequests is often suitable.
    4. Monitor Worker Restarts: Monitor your Workerman logs and process manager logs to ensure worker recycling is happening as configured and without unexpected errors.

  • Threats Mitigated:

    • Memory Leaks in Worker Processes (Medium Severity): PHP applications, especially with certain extensions or libraries, can experience memory leaks over time. Recycling workers prevents long-term memory accumulation and potential crashes.
    • Resource Accumulation in Worker Processes (Medium Severity): Even without explicit memory leaks, worker processes can accumulate resources like database connections, file handles, or internal state over time. Recycling provides a clean slate.
    • Mitigation of Long-Lived Compromised Processes (Medium Severity): If a vulnerability is exploited in a worker process, regular recycling limits the window of opportunity for an attacker to maintain persistence within that specific process instance.

  • Impact:

    • Memory Leaks: Significantly reduces the impact of memory leaks by preventing long-term accumulation and related instability.
    • Resource Accumulation: Significantly reduces the impact of resource accumulation, maintaining application stability and performance over time.
    • Long-Lived Compromised Processes: Partially reduces the risk by forcing attackers to re-establish any foothold after worker restarts.

  • Currently Implemented: Partially implemented.

    • Basic daily service restart via supervisorctl restart workerman is in place, which indirectly recycles workers.
    • Worker::$maxRequests or Worker::$maxEventLoops are not explicitly configured within the Workerman application code.

  • Missing Implementation:

    • Explicitly configure Worker::$maxRequests or Worker::$maxEventLoops in the Workerman application's Worker initialization.
    • Determine optimal values for maxRequests or maxEventLoops based on application load and resource usage patterns.
    • Implement monitoring specifically for worker restarts triggered by maxRequests or maxEventLoops to ensure it's functioning as expected.

Mitigation Strategy: Connection Limits and Rate Limiting (Workerman Specific)

  • Description:

    1. Implement Worker::$connections Limit: Utilize Worker::$connections to set a maximum number of concurrent connections a worker process will accept. This is a built-in Workerman mechanism to prevent resource exhaustion from excessive connections.
    2. Configure Connection Limit in Worker Initialization: Set the connections property when initializing your Worker instances: 
      use Workerman\Worker;

$ws_worker = new Worker("websocket://0.0.0.0:8484");
$ws_worker->count = 4;
$ws_worker->connections = 1000; // Limit to 1000 concurrent connections per worker
$ws_worker->onConnect = function($connection) {
    echo "new connection\n";
};
$ws_worker->onMessage = function($connection, $data) {
    $connection->send('hello ' . $data);
};

Worker::runAll();
    3. Implement Application-Level Rate Limiting in onConnect or onMessage: For more granular rate limiting based on IP address, user, or request type, implement custom rate limiting logic within your onConnect or onMessage callbacks.
      • Use a storage mechanism (e.g., Redis, Memcached, in-memory array with TTL) to track request counts or connection attempts per client.
      • In onConnect or onMessage, check the rate limit for the client's IP address or user identifier.
      • If the rate limit is exceeded, reject the connection or delay request processing.
    4. Consider Reverse Proxy Rate Limiting (Optional but Recommended for HTTP): If your Workerman application serves HTTP, leverage rate limiting features of a reverse proxy like Nginx or HAProxy in front of Workerman for initial DoS protection and offloading rate limiting logic.

  • Threats Mitigated:

    • Denial of Service (DoS) - Connection Floods (High Severity): Worker::$connections directly mitigates connection flood DoS attacks by limiting the number of concurrent connections a worker will handle, preventing resource exhaustion from excessive connections.
    • Brute-Force Attacks (Medium Severity): Application-level rate limiting can slow down or block brute-force attacks by limiting the number of login attempts or API requests from a single source within a time window.
    • Application-Level DoS (Medium Severity): Rate limiting can protect against application-level DoS attacks where attackers send a high volume of legitimate-looking requests to overwhelm the application logic.

  • Impact:

    • DoS - Connection Floods: Significantly reduces the risk. Worker::$connections provides a direct and effective defense against connection-based DoS.
    • Brute-Force Attacks: Partially reduces the risk. Rate limiting makes brute-force attacks slower and less effective, increasing the attacker's effort and detection probability.
    • Application-Level DoS: Partially reduces the risk. Rate limiting can mitigate some application-level DoS attacks, but may not be sufficient for sophisticated attacks.

  • Currently Implemented: Partially implemented.

    • Reverse proxy (Nginx) is in place, but rate limiting is not currently configured at the reverse proxy level.
    • Worker::$connections is not explicitly set in Workerman application code.
    • Application-level rate limiting is not implemented in onConnect or onMessage callbacks.

  • Missing Implementation:

    • Configure Worker::$connections in Workerman application's Worker initialization to limit concurrent connections per worker.
    • Implement application-level rate limiting in onConnect or onMessage callbacks, potentially using Redis or Memcached for rate limit tracking.
    • Configure rate limiting at the reverse proxy (Nginx) level for HTTP services to provide an initial layer of DoS protection.
    • Define appropriate rate limit thresholds based on expected traffic patterns and application capacity.

Mitigation Strategy: Secure WebSocket Handling (Workerman Specific - if using WebSockets)

  • Description:

    1. Validate WebSocket Origin Header: In the onWebSocketConnect callback, validate the $_SERVER['HTTP_ORIGIN'] header to prevent Cross-Site WebSocket Hijacking (CSWSH) attacks. Only allow connections from trusted origins. 
      use Workerman\Worker;

$ws_worker = new Worker("websocket://0.0.0.0:8484");
$ws_worker->onWebSocketConnect = function($connection, $http_header) {
    $allowed_origins = ['https://yourdomain.com', 'https://anotherdomain.com'];
    $origin = $_SERVER['HTTP_ORIGIN'] ?? '';
    if (!in_array($origin, $allowed_origins)) {
        $connection->close(); // Reject connection from untrusted origin
        return false;
    }
    return true; // Accept connection
};
// ... rest of WebSocket worker logic
    2. Implement WebSocket Message Validation: Apply strict input validation to all WebSocket messages received in the onMessage callback. Treat WebSocket messages as untrusted user input and validate data types, formats, and content to prevent injection vulnerabilities and unexpected behavior. (Refer to "Strict Input Validation" strategy for details).
    3. Secure WebSocket Authentication and Authorization: Implement proper authentication and authorization mechanisms for WebSocket connections. Do not rely on the assumption that WebSocket connections are inherently secure. Use methods like:
      • Token-based Authentication: Exchange tokens during the initial HTTP handshake or via a separate authentication flow before establishing the WebSocket connection. Validate tokens in onWebSocketConnect or onMessage.
      • Session-based Authentication: If using HTTP sessions, ensure session management is secure and session IDs are protected.
    4. Output Encoding for WebSocket Messages: Apply secure output encoding to all data sent back to WebSocket clients in the onMessage callback to prevent XSS vulnerabilities if the client-side application renders WebSocket data in a web context. (Refer to "Secure Output Encoding" strategy for details).

  • Threats Mitigated:

    • Cross-Site WebSocket Hijacking (CSWSH) (High Severity - WebSocket specific): Origin validation in onWebSocketConnect directly prevents CSWSH attacks by ensuring only connections from authorized origins are accepted.
    • WebSocket Injection Attacks (High Severity - WebSocket specific): Input validation of WebSocket messages prevents injection vulnerabilities within the WebSocket communication flow.
    • Unauthorized Access via WebSockets (High Severity - WebSocket specific): Lack of authentication and authorization allows unauthorized users to access WebSocket functionalities and data.
    • WebSocket-based XSS (Medium Severity - WebSocket specific): Improper output encoding of WebSocket messages can lead to XSS vulnerabilities if client-side applications render WebSocket data in a web browser.

  • Impact:

    • Cross-Site WebSocket Hijacking (CSWSH): Significantly reduces the risk. Origin validation is a primary defense against CSWSH.
    • WebSocket Injection Attacks: Significantly reduces the risk. Input validation is crucial for securing WebSocket message handling.
    • Unauthorized Access via WebSockets: Significantly reduces the risk. Proper authentication and authorization are essential for controlling access to WebSocket services.
    • WebSocket-based XSS: Significantly reduces the risk. Output encoding prevents XSS vulnerabilities arising from WebSocket message rendering.

  • Currently Implemented: Partially implemented.

    • Basic WebSocket functionality is implemented.
    • Origin validation in onWebSocketConnect is not implemented.
    • Input validation for WebSocket messages is inconsistent and not rigorously enforced.
    • WebSocket authentication and authorization are not fully implemented; relying on implicit security assumptions.
    • Output encoding for WebSocket messages is not consistently applied.

  • Missing Implementation:

    • Implement origin validation in onWebSocketConnect to prevent CSWSH attacks.
    • Implement robust input validation for all WebSocket messages received in onMessage.
    • Implement a secure WebSocket authentication and authorization mechanism (e.g., token-based).
    • Apply consistent output encoding to all WebSocket messages sent to clients to prevent XSS.
    • Regularly review and update the list of allowed origins for WebSocket connections.