Skip to content

Latest commit

 

History

History
46 lines (36 loc) · 4.99 KB

threat-modeling.md

File metadata and controls

46 lines (36 loc) · 4.99 KB

Threat Model Analysis for tencent/rapidjson

Threat: Deeply Nested Object DoS

  • Threat: Deeply Nested Object DoS

    • Description: An attacker sends a JSON payload with excessively deep nesting (e.g., [[[[[[[[...]]]]]]]]]). The attacker crafts this payload specifically to exhaust stack space during recursive parsing by RapidJSON's internal parsing functions.
    • Impact: Application crash due to stack overflow, leading to denial of service. The entire application becomes unavailable.
    • Affected RapidJSON Component: The core parsing engine, specifically the recursive descent parser used by default (functions related to ParseObject and ParseArray internally). The Reader class and its associated parsing methods are central.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • kParseMaxDepthFlag: Use the kParseMaxDepthFlag option during parsing to set a strict limit on the maximum nesting depth. Choose a reasonable depth based on your application's needs (e.g., 16, 32, or 64). This is the primary defense. Example: 
        rapidjson::Document doc;
rapidjson::ParseResult ok = doc.Parse<rapidjson::kParseMaxDepthFlag>(json_string, max_depth);
      • Iterative Parsing (SAX-style): If possible, use RapidJSON's SAX-style API. SAX parsers are event-driven and don't use recursion, making them inherently resistant to stack overflow attacks. This requires a different approach to processing the JSON data.
      • Input Size Limits: Implement limits on the overall size of the incoming JSON payload before it reaches RapidJSON.

Threat: Large String/Array Memory Exhaustion

  • Threat: Large String/Array Memory Exhaustion

    • Description: An attacker sends a JSON payload containing extremely large strings or arrays (e.g., a string with millions of characters, or an array with millions of elements). The attacker aims to cause RapidJSON to consume all available memory during allocation.
    • Impact: Application crash due to out-of-memory error, leading to denial of service. Potentially affects other processes on the same system.
    • Affected RapidJSON Component: Memory allocation functions within RapidJSON (e.g., those used by String, Value::SetString, Value::PushBack, etc.). The Allocator used by the Document is directly involved.
    • Risk Severity: High
    • Mitigation Strategies:
      • Schema Validation (with Limits): Use a JSON Schema validator that allows you to specify maxLength for strings and maxItems for arrays. This is the best approach.
      • Custom Allocator: Implement a custom allocator for RapidJSON that tracks memory usage and throws an exception or returns an error if a predefined limit is exceeded.
      • Input Size Limits: Limit the overall size of the incoming JSON payload before parsing.
      • Streaming (SAX-style): If you don't need the entire JSON document in memory at once, use the SAX-style API.

Threat: Integer Overflow/Underflow via RapidJSON's Number Parsing (Less Common, but Possible)

  • Threat: Integer Overflow/Underflow via RapidJSON's Number Parsing (Less Common, but Possible)

    • Description: While most integer overflow issues are due to application misuse, there could be edge cases where RapidJSON's internal number parsing logic, before returning the value to the application, might encounter an overflow during its internal calculations. This is less likely with well-tested libraries like RapidJSON, but still theoretically possible. For example, an extremely large number represented in scientific notation might cause an intermediate overflow within RapidJSON's parsing routines.
    • Impact: Potentially incorrect parsing results, leading to undefined behavior within RapidJSON itself. This could manifest as a crash, incorrect data being returned, or other unexpected behavior.
    • Affected RapidJSON Component: The internal number parsing logic within ParseNumber and related functions.
    • Risk Severity: High (because it's a bug within RapidJSON itself, if it exists)
    • Mitigation Strategies:
      • Stay Updated: Keep RapidJSON updated to the latest version. Such bugs, if they exist, are likely to be fixed in newer releases.
      • Fuzz Testing: If you are extremely concerned about this edge case, consider performing fuzz testing specifically targeting RapidJSON's number parsing with extremely large or unusual numeric inputs.
      • Schema Validation (with Numeric Limits): Using a schema validator with minimum and maximum values for numeric types can help prevent extremely large numbers from even reaching RapidJSON's parsing logic. This is a preventative measure.