Skip to content

Latest commit

 

History

History
105 lines (64 loc) · 9.29 KB

mitigations.md

File metadata and controls

105 lines (64 loc) · 9.29 KB

Mitigation Strategies Analysis for actix/actix-web

Mitigation Strategy: Request Rate Limiting (Actix-web Middleware)

Mitigation Strategy: Request Rate Limiting (Actix-web Middleware)

Description:

  1. Integrate Rate Limiting Middleware: Utilize Actix-web middleware, such as actix-web-limitation, to enforce rate limits directly within the application. This middleware intercepts incoming requests.
  2. Configure Middleware: Configure the middleware with specific rate limits (e.g., requests per second/minute) based on IP address or user identity. This configuration is done within the Actix-web application setup (e.g., in App::configure or HttpServer::configure).
  3. Customize Responses: The middleware automatically handles exceeding rate limits by returning 429 "Too Many Requests" responses. Customize error messages or response behavior within the middleware configuration if needed.
  4. Apply Globally or Route-Specific: Apply the middleware globally to the entire application or selectively to specific routes using Actix-web's middleware registration mechanisms.

List of Threats Mitigated:

  • Denial of Service (DoS) attacks: Severity: High. Actively limits excessive requests that can overwhelm the server's resources.
  • Brute-force attacks: Severity: Medium. Reduces the rate at which attackers can attempt credential stuffing or vulnerability exploitation.
  • Resource Exhaustion: Severity: Medium. Prevents a single source from monopolizing server resources through excessive requests.

Impact:

  • DoS attacks: High risk reduction. Significantly reduces the effectiveness of simple DoS attacks targeting application resources.
  • Brute-force attacks: Medium risk reduction. Slows down brute-force attempts, making them less efficient.
  • Resource Exhaustion: Medium risk reduction. Helps maintain application availability by preventing resource monopolization.

Currently Implemented: Yes, using actix-web-limitation middleware globally in src/main.rs within App::configure.

Missing Implementation: N/A - Rate limiting is applied to all routes using global middleware. Route-specific limits could be considered for future enhancement.

Mitigation Strategy: Request Body Size Limits (Actix-web Configuration)

Mitigation Strategy: Request Body Size Limits (Actix-web Configuration)

Description:

  1. Set Global Limit: Configure the maximum allowed request payload size using HttpServer::max_request_payload() when setting up the Actix-web HTTP server in src/main.rs. This sets a default limit for all requests handled by the server.
  2. Actix-web Enforcement: Actix-web automatically enforces this limit. If a request exceeds the configured size, Actix-web will reject the request and return a 413 "Payload Too Large" error.
  3. Error Handling (Optional): While Actix-web handles the rejection, you can customize error responses further using custom error handlers if needed, although the default 413 response is generally sufficient.

List of Threats Mitigated:

  • Denial of Service (DoS) attacks (Payload-based): Severity: High. Prevents attackers from sending extremely large payloads that can exhaust server memory or processing capacity.
  • Resource Exhaustion (Memory): Severity: Medium. Limits memory consumption by preventing the processing of excessively large request bodies.

Impact:

  • DoS attacks (Payload-based): High risk reduction. Effectively blocks payload-based DoS attacks at the framework level.
  • Resource Exhaustion (Memory): Medium risk reduction. Directly reduces the risk of memory exhaustion caused by oversized requests.

Currently Implemented: Yes, a global limit is set in HttpServer::max_request_payload() within src/main.rs.

Missing Implementation: Route-specific payload limits are not currently configured. Certain routes (e.g., file uploads in src/routes/upload.rs) might benefit from different, potentially larger, payload limits. This could be implemented using extractors or middleware on specific routes.

Mitigation Strategy: Input Validation using Actix-web Extractors and Validation Libraries

Mitigation Strategy: Input Validation using Actix-web Extractors and Validation Libraries

Description:

  1. Define Validatable Data Structures: Create data structures (structs) to represent expected request input (e.g., JSON bodies, query parameters). Use libraries like serde for deserialization and validator for defining validation rules directly on struct fields (using attributes like #[validate(length(min = 1, max = 255))]).
  2. Utilize Actix-web Extractors: In route handlers, use Actix-web extractors (Json, Query, Path, Form, Multipart) to extract and automatically deserialize incoming request data into these defined data structures.
  3. Extractor-Based Validation: When extractors are used with validatable data structures, Actix-web, in conjunction with libraries like validator, performs validation during the extraction process.
  4. Handle Extraction/Validation Errors: If validation fails during extraction, Actix-web returns an error. Implement error handling within your handlers or using custom error handlers to catch these extraction/validation errors and return appropriate 400 "Bad Request" responses with informative error messages.

List of Threats Mitigated:

  • Injection Attacks (SQL Injection, Command Injection, etc.): Severity: High. Prevents injection by ensuring input data conforms to expected formats and constraints before it reaches application logic.
  • Cross-Site Scripting (XSS): Severity: Medium. Reduces XSS risks by validating user inputs, minimizing the chance of malicious scripts being processed.
  • Business Logic Errors: Severity: Medium. Prevents errors caused by unexpected or invalid data entering the application's core logic.

Impact:

  • Injection Attacks: High risk reduction. Significantly reduces the attack surface for injection vulnerabilities by validating data at the framework entry point.
  • Cross-Site Scripting (XSS): Medium risk reduction. Contributes to XSS prevention by input validation, but output sanitization remains essential.
  • Business Logic Errors: Medium risk reduction. Improves application stability and reliability by ensuring data integrity.

Currently Implemented: Partially implemented. Validation using serde and validator is applied to JSON request bodies in API endpoints within src/api_routes.rs using the Json extractor.

Missing Implementation: Consistent input validation is not yet applied to all input sources. Query parameters and path parameters in various routes, and form data in web forms within src/web_routes.rs, still require comprehensive validation using extractors and validation libraries.

Mitigation Strategy: Custom Error Handlers (Actix-web Error Handling)

Mitigation Strategy: Custom Error Handlers (Actix-web Error Handling)

Description:

  1. Define Custom Error Handlers: Create functions that serve as custom error handlers. These functions take an Error and HttpRequest as input and return a ServiceResponse.
  2. Register Error Handlers: Register these custom error handlers within your Actix-web application setup using App::default_service or ServiceConfig::default_service. This tells Actix-web to use your custom handlers when specific errors occur (e.g., 404 Not Found, 500 Internal Server Error, or custom application errors).
  3. Implement Generic Responses: Within your custom error handlers, ensure that for production environments, you return generic error responses to clients. Avoid including sensitive information like stack traces, internal paths, or detailed error messages in these responses. Return standard HTTP error status codes and user-friendly, generic messages.
  4. Conditional Detailed Errors (Optional): For development or debugging environments, you can conditionally include more detailed error information in the response, but this should be disabled in production builds.

List of Threats Mitigated:

  • Information Disclosure: Severity: High. Prevents accidental or intentional leakage of sensitive internal application details through default error pages or verbose error messages.
  • Security Misconfiguration: Severity: Medium. Reduces the risk of relying on default error handling that may expose unnecessary information.

Impact:

  • Information Disclosure: High risk reduction. Effectively prevents information leakage through error responses by controlling the content of error messages sent to clients.
  • Security Misconfiguration: Medium risk reduction. Improves the security posture by ensuring error responses are controlled and do not reveal sensitive data.

Currently Implemented: Yes, a custom error handler is defined in src/error_handlers.rs and registered in main.rs using App::default_service for the production environment.

Missing Implementation: N/A - Custom error handling is globally applied for unhandled errors and default services.