Skip to content

Latest commit

 

History

History
75 lines (56 loc) · 7.43 KB

mitigations.md

File metadata and controls

75 lines (56 loc) · 7.43 KB

Mitigation Strategies Analysis for gleam-lang/gleam

Mitigation Strategy: Strict Type Checking and Data Validation (Gleam-Centric)

  • Description:

    1. Define Custom Types (Gleam): For every piece of data coming from an external source (or even internal functions if appropriate), create a specific Gleam type. This type should precisely define the allowed structure and values. Don't rely on generic types like Int or String when more specific constraints are possible. Example: type EmailAddress = EmailAddress(String) with a validating function fn is_valid_email(s: String) -> Bool { ... }.
    2. Pattern Matching (Gleam): Use Gleam's pattern matching extensively to deconstruct incoming data and ensure it conforms to your custom types. This should be the very first step in any function that receives external data. Use guards within pattern matching for additional checks.
    3. Result Type for Validation (Gleam): Write validation functions that return Result(ValidType, ErrorType). This forces the calling code to explicitly handle potential validation failures. Never ignore the Error case. Example: fn validate_user_input(input: String) -> Result(User, InputError) { ... }.
    4. Reject Invalid Data Early (Gleam): If validation (using your Result types) fails, return an error immediately. Do not proceed with any further processing of invalid data. Use clear and informative error messages.
    5. Explicit Error Handling (Gleam): Use Gleam's Result type and pattern matching to handle all possible error cases. Avoid using panic! unless it's truly an unrecoverable situation (like a configuration error at startup). Create custom error types to provide context.

  • Threats Mitigated:

    • Untrusted External Data (Gleam Code): (Severity: High) - Prevents processing of malformed or malicious data that could lead to code injection (if interacting with unsafe Erlang code), logic errors, or crashes within Gleam code.
    • Data Corruption (Gleam Code): (Severity: Medium) - Ensures data integrity within Gleam by enforcing strict type and value constraints.

  • Impact:

    • Untrusted External Data: Significantly reduces risk. Gleam's type system, when used correctly, makes it very difficult to process invalid data.
    • Data Corruption: Significantly reduces risk by preventing invalid data from propagating through the Gleam codebase.

  • Currently Implemented: (Example - Adapt to your project)

    • src/http/handlers.gleam: Custom types and validation functions (returning Result) are used for all incoming HTTP request data.
    • src/models.gleam: Custom types are used to represent all application data structures.

  • Missing Implementation: (Example - Adapt to your project)

    • src/utils.gleam: Some utility functions that process strings don't use custom types or thorough validation.

Mitigation Strategy: Safe Erlang Interop (Gleam Wrappers)

  • Description:

    1. Identify FFI Calls (Gleam): Find all places in your Gleam code where you use external to call Erlang functions.
    2. Create Gleam Wrapper Functions: For each Erlang FFI call, create a corresponding Gleam function. This wrapper function will be your only point of interaction with the Erlang code.
    3. Type Validation in Wrappers (Gleam): Inside the wrapper function:
      • Call the Erlang function.
      • Immediately validate the return value from Erlang against expected Gleam types. Use pattern matching and guards. Treat the Erlang return value as potentially untrusted.
      • Convert the Erlang value to a Gleam type (if necessary), ensuring type safety.
      • Return a Result(GleamType, ErrorType) to indicate success or failure of the call and validation.
    4. Handle Erlang Exceptions (Gleam): Use Gleam's try expression to catch any exceptions that might be raised by the Erlang code. Convert these exceptions into Gleam Error values within your Result.
    5. Document Assumptions (Gleam): In the Gleam wrapper function's documentation, clearly state any assumptions you're making about the Erlang function's behavior (input types, return types, potential errors).

  • Threats Mitigated:

    • Erlang Interop Vulnerabilities (Gleam Side): (Severity: Medium) - Prevents type-related errors and unexpected behavior when interacting with Erlang's dynamically typed code. This is crucial for maintaining Gleam's type safety guarantees.
    • Untrusted External Data (via Erlang, handled in Gleam): (Severity: Medium) - If the Erlang code you're calling interacts with external data, this mitigation ensures that the data is validated before it's used within your Gleam code.

  • Impact:

    • Erlang Interop Vulnerabilities: Significantly reduces risk by providing a type-safe and error-checked layer around all Erlang interactions from Gleam.
    • Untrusted External Data (via Erlang): Reduces risk by ensuring that any data coming from Erlang is validated according to Gleam's type system.

  • Currently Implemented: (Example)

    • src/erlang_interop/safe_json.gleam: Provides Gleam wrapper functions for Erlang's JSON encoding/decoding, with thorough type validation.

  • Missing Implementation: (Example)

    • src/erlang_interop/database.gleam: Some wrapper functions for database interactions don't fully validate the data returned from Erlang.

Mitigation Strategy: Avoid Unbounded Recursion (Gleam)

  • Description:

    1. Identify Recursive Functions (Gleam): Examine your Gleam code for any functions that call themselves, either directly or indirectly.
    2. Ensure Base Cases (Gleam): For every recursive function, verify that there is a well-defined base case (or cases) that will always be reached, preventing infinite recursion.
    3. Analyze Call Depth (Gleam): Consider the maximum possible depth of recursion. If the depth could be very large (especially if it depends on external input), consider refactoring to use iteration or tail recursion (if possible). Gleam's compiler optimizes tail-recursive functions.
    4. Test with Large Inputs (Gleam): If the recursion depth depends on input size, test your functions with large inputs to ensure they don't cause stack overflows.

  • Threats Mitigated:

    • Stack Overflow (Gleam): (Severity: High) - Prevents crashes due to excessive stack usage caused by unbounded recursion.
    • Denial of Service (DoS - via Recursion): (Severity: Medium) - Reduces the risk of an attacker triggering excessive recursion with crafted input, leading to resource exhaustion.

  • Impact:

    • Stack Overflow: Significantly reduces risk. Properly implemented base cases prevent infinite recursion.
    • Denial of Service (DoS - via Recursion): Reduces risk by limiting the potential for attackers to exploit recursive functions.

  • Currently Implemented: (Example)

    • Most recursive functions in src/data_processing.gleam have clear base cases.

  • Missing Implementation: (Example)

    • src/parser.gleam: The parsing logic uses recursion, and the maximum recursion depth is not well-defined. It needs to be analyzed and potentially refactored.