Skip to content

Latest commit

 

History

History
100 lines (75 loc) · 7.29 KB

mitigations.md

File metadata and controls

100 lines (75 loc) · 7.29 KB

Mitigation Strategies Analysis for johnezang/jsonkit

Mitigation Strategy: Strict Schema Validation (Pre-Decoding)

Description:

  1. Define a JSON Schema: Create a formal JSON schema definition that precisely describes the expected structure and data types of the JSON input.
  2. Choose a Validation Library: Select a Go JSON schema validation library (e.g., github.com/santhosh-tekuri/jsonschema, github.com/xeipuuv/gojsonschema).
  3. Integrate Validation: Before any call to jsonkit.Unmarshal (or any jsonkit decoding function), validate the raw JSON input (as a []byte or string) against the schema using the chosen library.
  4. Handle Validation Errors: If validation fails, reject the input immediately. Do not call jsonkit's decoding function. Log the error and return a generic error message.
  5. Schema Versioning: Update the schema and ensure all parts of your application use the correct version if the expected JSON structure changes.

Threats Mitigated:

  • Malformed JSON Input: (Severity: High) - Prevents jsonkit from processing invalid JSON.
  • Unexpected Data Types: (Severity: Medium) - Ensures jsonkit receives correctly typed data.
  • Excessive Data: (Severity: Medium) - Schema constraints limit the scope of resource exhaustion attacks that jsonkit might be vulnerable to.
  • Injection of Extra Fields: (Severity: Medium) - Prevents jsonkit from processing unexpected fields.

Impact:

  • Malformed JSON Input: Risk reduced significantly (High impact).
  • Unexpected Data Types: Risk reduced significantly (High impact).
  • Excessive Data: Risk reduced moderately (Medium impact).
  • Injection of Extra Fields: Risk reduced significantly (High impact).

Currently Implemented: (Example - Replace with your project's status)

  • Partially implemented. Schema validation is present for /api/user (in user_handler.go) before calling jsonkit.Unmarshal, but not for /api/config.

Missing Implementation: (Example - Replace with your project's status)

  • Missing for /api/config. jsonkit.Unmarshal is called directly without validation.
  • Schema for /api/user lacks maximum string length constraints, which should be added before the jsonkit call.

Mitigation Strategy: Fuzz Testing of jsonkit Decoding

Description:

  1. Choose a Fuzzer: Select a Go fuzzing tool (e.g., go-fuzz or a modern alternative).
  2. Write Fuzz Tests: Create fuzz tests that specifically target jsonkit's decoding functions (e.g., jsonkit.Unmarshal). These tests should take a []byte (raw JSON) and call the jsonkit function.
  3. Run Fuzzer: Run the fuzzer extensively to generate diverse, malformed JSON inputs.
  4. Analyze Crashes/Panics: Analyze any crashes or panics reported by the fuzzer to identify vulnerabilities in jsonkit's handling of edge cases.
  5. Integrate into CI/CD: Integrate fuzz testing into your CI/CD pipeline.

Threats Mitigated:

  • Unexpected Parsing Behavior in jsonkit: (Severity: High) - Finds edge cases and subtle parsing errors within jsonkit itself.
  • Denial-of-Service (DoS) via jsonkit Panics: (Severity: High) - Identifies inputs that cause jsonkit to panic.
  • Memory Corruption (Unlikely, but Possible in jsonkit): (Severity: Critical) - Could potentially reveal memory issues if jsonkit has unsafe code.

Impact:

  • Unexpected Parsing Behavior in jsonkit: Risk reduced significantly (High impact).
  • Denial-of-Service (DoS) via jsonkit Panics: Risk reduced significantly (High impact).
  • Memory Corruption: Risk reduced (Low probability, but high impact if found).

Currently Implemented: (Example - Replace with your project's status)

  • Not implemented. No fuzz tests target jsonkit's decoding functions.

Missing Implementation: (Example - Replace with your project's status)

  • Fuzz tests specifically for jsonkit need to be written and integrated.

Mitigation Strategy: Resource Limits (Applied Before jsonkit Call)

Description:

  1. Maximum Input Size: Before passing data to jsonkit, enforce a strict maximum size limit on the JSON payload. This can be done at the network layer (reverse proxy/API gateway) or in application code (e.g., io.LimitedReader). The key is to prevent a large payload from ever reaching jsonkit.
  2. Context Timeouts: Wrap the call to jsonkit.Unmarshal (or equivalent) within a context.WithTimeout. This limits the time jsonkit has to process the input.
  3. Memory limits: Use debug.SetMemoryLimit to limit memory usage.

Threats Mitigated:

  • Denial-of-Service (DoS) via Large Payloads (targeting jsonkit): (Severity: High) - Prevents jsonkit from even attempting to process excessively large inputs.
  • Denial-of-Service (DoS) via Deep Nesting (targeting jsonkit): (Severity: High) - Timeouts limit the time jsonkit spends on deeply nested structures.

Impact:

  • Denial-of-Service (DoS) via Large Payloads: Risk reduced significantly (High impact).
  • Denial-of-Service (DoS) via Deep Nesting: Risk reduced significantly (High impact).

Currently Implemented: (Example - Replace with your project's status)

  • Partially implemented. A global timeout of 5 seconds is applied to all HTTP requests, but no specific input size limit is enforced before calling jsonkit.

Missing Implementation: (Example - Replace with your project's status)

  • A maximum input size limit needs to be implemented before the data is passed to jsonkit.

Mitigation Strategy: Robust Error Handling (of jsonkit Errors)

Description:

  1. Check Errors: Always check the error value returned by any jsonkit function (e.g., jsonkit.Unmarshal).
  2. Handle Errors Gracefully: Do not ignore errors from jsonkit.
    • Log the Error: Log the full error details from jsonkit for debugging (protect these logs).
    • Return Generic Error: Return a generic error message to the user/client that does not reveal any details from the jsonkit error.
    • Consider Retries (if appropriate): For transient errors.
  3. Don't Panic: Avoid panicking on errors from jsonkit unless absolutely necessary.

Threats Mitigated:

  • Information Disclosure (from jsonkit errors): (Severity: Medium) - Prevents leaking internal details from jsonkit's error messages.
  • Unexpected Application Behavior (due to unhandled jsonkit errors): (Severity: Medium)

Impact:

  • Information Disclosure: Risk reduced significantly (Medium impact).
  • Unexpected Application Behavior: Risk reduced significantly (Medium impact).

Currently Implemented: (Example - Replace with your project's status)

  • Partially implemented. Errors from jsonkit.Unmarshal are checked, but the raw jsonkit error message is sometimes included in the HTTP response.

Missing Implementation: (Example - Replace with your project's status)

  • Ensure that all error messages returned to the user are generic and never include the raw error from jsonkit.