Skip to content

Latest commit

 

History

History
72 lines (60 loc) · 5.26 KB

attack-surface.md

File metadata and controls

72 lines (60 loc) · 5.26 KB

Attack Surface Analysis for valyala/fasthttp

Attack Surface: HTTP Request Smuggling/Splitting (HRS)

  • Description: Exploits differences in how fasthttp and intermediary systems parse HTTP requests, allowing request smuggling or splitting.
    • How fasthttp Contributes: fasthttp's non-standard, performance-optimized HTTP parsing creates the discrepancies that enable HRS. This is a direct consequence of fasthttp's design.
    • Example: 
      POST / HTTP/1.1
Host: example.com
Content-Length: 5
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: example.com
      fasthttp might process the entire payload, while a proxy sees only the initial POST.
    • Impact:
      • Bypassing security controls.
      • Accessing restricted resources.
      • Cache poisoning.
      • Session hijacking.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Use a Standard-Compliant Reverse Proxy: A reverse proxy (Nginx, HAProxy) is the primary defense, normalizing requests before they reach fasthttp. This is crucial, but I'm including it because the vulnerability originates in fasthttp.
      • Fuzzing: Extensive fuzzing of fasthttp's request parsing, specifically targeting HRS scenarios (conflicting headers, malformed chunked encoding). This is a direct mitigation against fasthttp's parsing.
      • Disable Transfer-Encoding: chunked (If Possible): If chunked encoding is not strictly required, disabling it on the fasthttp server reduces the attack surface. This directly modifies fasthttp's behavior.

Attack Surface: Buffer Overflow/Underflow in fasthttp's Parsing

  • Description: Bugs in fasthttp's custom buffer management and request parsing can lead to buffer overflows/underflows.
    • How fasthttp Contributes: This is entirely due to fasthttp's internal implementation of memory management and parsing.
    • Example: An extremely long header value or a malformed chunked encoding sequence could trigger an overflow if fasthttp has a bug in its bounds checking.
    • Impact:
      • Remote Code Execution (RCE).
      • Denial of Service (DoS) via crashes.
      • Potential information disclosure.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Keep fasthttp Updated: This is the most direct mitigation – rely on the fasthttp developers to fix these low-level bugs.
      • Extensive Fuzzing: Use fuzzing tools (AFL, libFuzzer) to specifically target fasthttp's parsing logic for buffer overflows. This directly tests fasthttp's code.
      • Limit Header Sizes: Configure fasthttp's MaxHeaderSize to reject excessively large headers. This is a direct configuration change to fasthttp.

Attack Surface: Connection Desynchronization

  • Description: Improper handling of connection reuse in fasthttp can cause requests from different clients to be mixed.
    • How fasthttp Contributes: This vulnerability stems directly from fasthttp's connection reuse mechanism, a core part of its design.
    • Example: Data from one client's request (headers, cookies) leaks into the processing of a subsequent request from a different client on the same reused connection.
    • Impact:
      • Information disclosure (session cookies, etc.).
      • Unauthorized access.
      • Data corruption.
    • Risk Severity: High
    • Mitigation Strategies:
      • Thorough Concurrency Testing: Intense testing under high concurrent load with persistent connections is crucial to identify this fasthttp-specific issue.
      • Review fasthttp Code (Advanced): Examine fasthttp's connection handling code for potential bugs (requires deep expertise). This is a direct examination of fasthttp.
      • Disable Keep-Alive (Extreme): Disabling keep-alive completely eliminates the risk, but severely impacts performance. This directly modifies fasthttp's behavior.

Attack Surface: Denial of Service (DoS) via Memory Exhaustion (Targeting fasthttp)

  • Description: Crafted requests exploit fasthttp's internal memory allocation to cause excessive memory use.
    • How fasthttp Contributes: This targets vulnerabilities in fasthttp's custom memory management, a core part of its design.
    • Example: A request with thousands of unique, long header names might cause fasthttp to allocate excessive memory.
    • Impact: Denial of Service (DoS).
    • Risk Severity: High
    • Mitigation Strategies:
      • Limit Request Sizes: Use fasthttp's configuration: MaxHeaderSize, MaxRequestBodySize. These directly control fasthttp's behavior.
      • Fuzzing: Fuzz fasthttp with requests designed to stress its memory allocation (large headers, many parameters). This directly tests fasthttp.