daemon-sec-cheatsheet

The cheatsheet vault for operators: AD, enumeration, exploitation, priv-esc, web, DFIR
git clone https://git.daemon-sec.xyz/daemon-sec-cheatsheet.git
Log | Files | Refs | README | LICENSE

abusing-hop-by-hop-headers.md (4158B)


      1 ---
      2 title: "Abusing Hop-by-Hop Headers"
      3 section: "Web Pentesting"
      4 sectionSlug: "pentesting-web"
      5 sourcePath: "src/pentesting-web/abusing-hop-by-hop-headers.md"
      6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/abusing-hop-by-hop-headers.md"
      7 sha: "188de82beb54e70956b2952367a0af91d26758b8"
      8 isIndex: false
      9 modified: true
     10 license: "CC-BY-NC-4.0"
     11 ---
     12 
     13 # Abusing Hop-by-Hop Headers
     14 
     15 ---
     16 
     17 **This is a summary of the post** [**https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers**](https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers)<sup>[[1]](#references)</sup>
     18 
     19 Hop-by-hop fields apply only to one transport connection and must not be forwarded by a proxy. In HTTP/1.1, `Connection` names any additional fields that the recipient must consume and remove before forwarding. Current RFC 9110 defines `Connection`, `Keep-Alive`, `Proxy-Authenticate`, `Proxy-Authorization`, `TE`, `Trailer`, `Transfer-Encoding`, and `Upgrade` as hop-by-hop fields. HTTP/2 and HTTP/3 prohibit connection-specific fields, except the narrowly defined `TE: trailers` case.<sup>[[2]](#references)</sup>
     20 
     21 ### Abusing Hop-by-Hop Headers
     22 
     23 Security problems arise when front-end and back-end components disagree about which fields were removed or which component was responsible for a control. For example, `Connection: X-Forwarded-For` can cause one proxy to strip an authentication-relevant field before the request reaches a later component.<sup>[[1]](#references)</sup>
     24 
     25 ### Testing for Hop-by-Hop Header Handling
     26 
     27 The handling of hop-by-hop headers can be tested by observing changes in server responses when specific headers are marked as hop-by-hop. Tools and scripts can automate this process, identifying how proxies manage these headers and potentially uncovering misconfigurations or proxy behaviors.
     28 
     29 Abusing hop-by-hop headers can lead to various security implications. Below are a couple of examples demonstrating how these headers can be manipulated for potential attacks:
     30 
     31 ### Bypassing Security Controls with `X-Forwarded-For`
     32 
     33 An attacker can nominate `X-Forwarded-For` as hop-by-hop to make a compliant intermediary remove it. The exploit is not that the proxy forwards a spoofed value; it is that a downstream component may fail open when the trusted provenance field is unexpectedly absent.
     34 
     35 **Attack Scenario:**
     36 
     37 1. The attacker sends an HTTP request to a web application behind a proxy, including a fake IP address in the `X-Forwarded-For` header.
     38 2. The attacker also includes the `Connection: close, X-Forwarded-For` header, prompting the proxy to treat `X-Forwarded-For` as hop-by-hop.
     39 3. The misconfigured proxy forwards the request to the web application without the spoofed `X-Forwarded-For` header.
     40 4. The web application, not seeing the original `X-Forwarded-For` header, might consider the request as coming directly from a trusted proxy, potentially allowing unauthorized access.
     41 
     42 ### Cache Poisoning via Hop-by-Hop Header Injection
     43 
     44 If a nominated field changes an origin response but is omitted from the cache key, a cache may store the attacker-influenced response and serve it to other users. Whether `Cookie` can be nominated, removed, and cached this way depends on the exact intermediary chain and cache policy; confirm each hop instead of assuming the scenario works generically.<sup>[[1]](#references)</sup>
     45 
     46 **Attack Scenario:**
     47 
     48 1. An attacker sends a request to a web application with a hop-by-hop header that should not be cached (e.g., `Connection: close, Cookie`).
     49 2. The poorly configured cache server does not remove the hop-by-hop header and caches the response specific to the attacker's session.
     50 3. Future users requesting the same resource receive the cached response, which was tailored for the attacker, potentially leading to session hijacking or exposure of sensitive information.
     51 
     52 ## References
     53 
     54 - [1] [Abusing HTTP hop-by-hop request headers](https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers)
     55 - [2] [RFC 9110, section 7.6.1 — Connection](https://www.rfc-editor.org/rfc/rfc9110.html#section-7.6.1)