Skip to content

Latest commit

 

History

History
171 lines (135 loc) · 12 KB

mitigations.md

File metadata and controls

171 lines (135 loc) · 12 KB

Mitigation Strategies Analysis for rwf2/rocket

Mitigation Strategy: Secure Configuration Storage (Rocket-Specific Aspects)

Mitigation Strategy: Leverage Rocket's configuration system correctly to securely manage sensitive data, avoiding hardcoding in Rocket.toml or source code.

Description:

  1. Identify Sensitive Data: List all configuration values needing protection (API keys, database credentials, etc.).
  2. Choose Storage (Rocket-Aware):
    • Environment Variables: Use Rocket's built-in support for environment variables. Access them via std::env::var within your Rocket application, not directly in Rocket.toml. Rocket automatically reads environment variables prefixed with ROCKET_.
    • Custom Config Providers (Advanced): For complex scenarios or integration with secrets management services, implement a custom configuration provider for Rocket. This allows you to fetch configuration from external sources securely.
  3. Remove Hardcoded Secrets: Eliminate all hardcoded secrets from Rocket.toml and your Rust code.
  4. Access via Rocket's System: Use Config::figment() or the Rocket::custom() method to build your Rocket instance, ensuring that configuration is loaded from the chosen secure source (environment variables or your custom provider).
  5. Typed Configuration: Utilize Rocket's typed configuration features. Define structs that represent your configuration and use them to deserialize the configuration data. This provides compile-time safety and validation.
  6. Rotation: Implement secret rotation policy.

Threats Mitigated:

  • Credential Exposure (Severity: Critical): Prevents attackers from obtaining credentials if they access the source code or Rocket.toml.
  • Configuration Tampering (Severity: High): Makes it harder to modify configuration maliciously.
  • Accidental Disclosure (Severity: Medium): Reduces the risk of accidentally committing secrets.

Impact:

  • Credential Exposure: Risk significantly reduced (Critical to Low/Negligible).
  • Configuration Tampering: Risk significantly reduced (High to Medium/Low).
  • Accidental Disclosure: Risk significantly reduced (Medium to Low).

Currently Implemented:

  • Partially. Environment variables are used for the database connection string, accessed via std::env::var in src/db.rs.

Missing Implementation:

  • API keys are hardcoded in src/services/third_party.rs. These need to be managed via environment variables or a custom config provider.
  • No custom configuration provider is implemented.
  • No secret rotation policy implemented.

Mitigation Strategy: Strict Route Matching (Rocket-Specific)

Mitigation Strategy: Use precise route definitions, leveraging Rocket's type-safe routing capabilities to avoid unintended handler execution.

Description:

  1. Review Routes: Examine all #[get], #[post], etc., attributes in your Rocket application.
  2. Identify Ambiguity: Look for routes that could match unintended requests.
  3. Refine with Rocket Types: Use Rocket's specific parameter types:
    • Instead of "/users/<id>" use "/users/<id:usize>".
    • Use "/files/<filename:PathBuf>" to ensure filename is a valid path segment.
    • Use Option<T> for optional parameters only with default values or graceful None handling. Leverage Rocket's support for Option in route parameters.
    • Use custom types and implement the FromParam trait for complex parameter validation.
  4. Test with Rocket's Testing Framework: Use Rocket's built-in testing framework (rocket::local::Client) to write unit tests that specifically verify route matching, including negative tests (requests that shouldn't match).

Threats Mitigated:

  • Request Hijacking (Severity: High): Prevents crafting requests that unintentionally match sensitive routes.
  • Unexpected Handler Execution (Severity: Medium): Reduces the risk of handlers running with unexpected input.
  • Information Disclosure (Severity: Medium): Limits access, reducing potential leaks through unintended handler calls.

Impact:

  • Request Hijacking: Risk significantly reduced (High to Medium/Low).
  • Unexpected Handler Execution: Risk significantly reduced (Medium to Low).
  • Information Disclosure: Risk moderately reduced (Medium to Low/Negligible).

Currently Implemented:

  • Mostly. Most routes use specific types (e.g., usize, String).

Missing Implementation:

  • /admin/<action> in src/admin.rs is too broad. Split into more specific routes.
  • More comprehensive unit tests using rocket::local::Client are needed.

Mitigation Strategy: Request Guard Validation (Rocket-Specific)

Mitigation Strategy: Extensively use Rocket's request guards to enforce pre-conditions on requests before handler execution.

Description:

  1. Identify Validation Needs: For each route, determine what to validate: HTTP method, headers, body data, authentication, authorization.
  2. Use Built-in Guards: Use Rocket's built-in guards:
    • MethodGuard: Check the HTTP method.
    • ContentType: Validate the Content-Type header.
    • Accept: Validate the Accept header.
  3. Create Custom Guards: Implement custom request guards (implementing the FromRequest trait) for:
    • Authentication: Verify user identity (e.g., using JWTs, sessions).
    • Authorization: Check user permissions.
    • CSRF Protection: Validate CSRF tokens.
    • Custom Header Validation: Check for specific headers or header values.
    • Request Body Validation: Validate the structure and content of the request body (often used in conjunction with FromData).
  4. Apply Guards: Attach guards to routes using #[guard] or by adding them to the Rocket instance.
  5. Fail Fast (Rocket-Specific): Request guards should return a rocket::outcome::Outcome immediately. Use Outcome::Failure with appropriate HTTP status codes (400, 401, 403) to reject invalid requests.
  6. Test with Rocket: Use rocket::local::Client to test that guards correctly enforce validation and return appropriate error responses.

Threats Mitigated:

  • Authentication Bypass (Severity: Critical): Authentication guards prevent unauthorized access.
  • Authorization Bypass (Severity: Critical): Authorization guards ensure users only access permitted resources.
  • Invalid Input (Severity: High): Guards validate data, preventing many injection attacks.
  • CSRF (Severity: High): CSRF protection guards mitigate CSRF attacks.
  • DoS (Severity: Medium): Guards can limit request body sizes.

Impact:

  • Authentication/Authorization Bypass: Risk significantly reduced (Critical to Low/Negligible).
  • Invalid Input: Risk significantly reduced (High to Medium/Low).
  • CSRF: Risk significantly reduced (High to Low, with CSRF protection).
  • DoS: Risk moderately reduced (Medium to Low).

Currently Implemented:

  • Basic authentication guards on some routes in src/api/private.rs.
  • ContentType guard on routes accepting JSON.

Missing Implementation:

  • No authorization guards.
  • No CSRF protection.
  • No request body size limits.
  • More comprehensive guards for input validation are needed.

Mitigation Strategy: Fairing Auditing and Management (Rocket-Specific)

Mitigation Strategy: Carefully review, manage, and order Rocket fairings to minimize vulnerabilities.

Description:

  1. Inventory: List all fairings (built-in and third-party).
  2. Source Verification (Third-Party): Verify the source and reputation of third-party fairing developers.
  3. Code Review (Third-Party): Review the source code of all third-party fairings for potential security issues.
  4. Dependency Updates: Keep all fairings updated.
  5. Fairing Ordering (Rocket-Specific): Understand the order of fairing execution (using attach on the Rocket instance). Place security-related fairings (authentication, authorization, rate limiting) early in the chain. This ensures they are applied before any potentially vulnerable code.
  6. Minimal Fairings: Only use necessary fairings.
  7. Testing (Rocket-Specific): Use rocket::local::Client to test the application with all fairings enabled, including security testing. Test how fairings interact with each other.

Threats Mitigated:

  • Vulnerabilities in Third-Party Code (Severity: High/Critical): Reduces risk from third-party fairings.
  • Unexpected Fairing Interactions (Severity: Medium): Prevents issues from fairing interactions.
  • Supply Chain Attacks (Severity: High): Reduces risk by verifying sources and updating.

Impact:

  • Vulnerabilities in Third-Party Code: Risk significantly reduced (High/Critical to Medium/Low).
  • Unexpected Fairing Interactions: Risk moderately reduced (Medium to Low).
  • Supply Chain Attacks: Risk significantly reduced (High to Medium).

Currently Implemented:

  • A few built-in Rocket fairings are used.
  • One third-party fairing (rocket_cors).

Missing Implementation:

  • No code review of rocket_cors.
  • No regular fairing update schedule.
  • Fairing ordering hasn't been explicitly considered.

Mitigation Strategy: FromData and FromForm Implementation (Rocket-Specific)

Mitigation Strategy: Carefully implement and validate data received through Rocket's FromData and FromForm traits to prevent vulnerabilities related to request body parsing.

Description:

  1. Understand FromData Variants: Be aware of the differences between FromDataSimple (for streaming data) and FromData (for buffered data). Choose the appropriate trait based on your needs.
  2. Data Limits: Set appropriate data limits using Limits::new() in your Rocket configuration. This prevents denial-of-service attacks through excessively large request bodies. Configure limits for both the overall request size and individual form fields.
  3. Strict Validation: Implement thorough validation for any data received through FromData or FromForm. Use Rocket's built-in validation features (e.g., validate crate integration) or implement custom validation logic within your FromData or FromForm implementation.
  4. Type Safety: Use strongly-typed structs to represent the data you expect to receive. This helps prevent type confusion vulnerabilities.
  5. Error Handling: Handle errors gracefully within your FromData or FromForm implementation. Return appropriate error responses (e.g., 400 Bad Request) if the data is invalid.
  6. Testing: Use rocket::local::Client to test your FromData and FromForm implementations with various inputs, including valid, invalid, and malicious data.

Threats Mitigated:

  • Denial of Service (DoS) (Severity: Medium): Data limits prevent attackers from sending excessively large requests.
  • Invalid Input (Severity: High): Strict validation prevents many types of injection attacks.
  • Type Confusion (Severity: Medium): Type safety helps prevent vulnerabilities related to incorrect data types.

Impact:

  • DoS: Risk reduced moderately (from Medium to Low).
  • Invalid Input: Risk significantly reduced (from High to Medium/Low).
  • Type Confusion: Risk reduced (from Medium to Low).

Currently Implemented:

  • FromForm is used in several places to handle form data.

Missing Implementation:

  • Data limits are not explicitly configured.
  • Validation is basic and relies primarily on the validate crate. More comprehensive custom validation is needed in some cases.
  • Error handling within FromForm implementations could be improved.
  • More thorough testing with rocket::local::Client is required.