References: numbered citations (batch 3)

src/pentesting-web/abusing-hop-by-hop-headers.md

@@ -6,21 +6,21 @@
 
 **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)
 
-Hop-by-hop headers are specific to a single transport-level connection, used primarily in HTTP/1.1 for managing data between two nodes (like client-proxy or proxy-proxy), and are not meant to be forwarded. Standard hop-by-hop headers include `Keep-Alive`, `Transfer-Encoding`, `TE`, `Connection`, `Trailer`, `Upgrade`, `Proxy-Authorization`, and `Proxy-Authenticate`, as defined in [RFC 2616](https://tools.ietf.org/html/rfc2616#section-13.5.1). Additional headers can be designated as hop-by-hop via the `Connection` header.
+Hop-by-hop headers are specific to a single transport-level connection, used primarily in HTTP/1.1 for managing data between two nodes (like client-proxy or proxy-proxy), and are not meant to be forwarded. Standard hop-by-hop headers include `Keep-Alive`, `Transfer-Encoding`, `TE`, `Connection`, `Trailer`, `Upgrade`, `Proxy-Authorization`, and `Proxy-Authenticate`, as defined in [RFC 2616](https://tools.ietf.org/html/rfc2616#section-13.5.1). Additional headers can be designated as hop-by-hop via the `Connection` header.<sup>[[1]](#references)</sup>
 
 ### Abusing Hop-by-Hop Headers
 
-Improper management of hop-by-hop headers by proxies can lead to security issues. While proxies are expected to remove these headers, not all do, creating potential vulnerabilities.
+Improper management of hop-by-hop headers by proxies can lead to security issues. While proxies are expected to remove these headers, not all do, creating potential vulnerabilities.<sup>[[1]](#references)</sup>
 
 ### Testing for Hop-by-Hop Header Handling
 
-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.
+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.<sup>[[1]](#references)</sup>
 
 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:
 
 ### Bypassing Security Controls with `X-Forwarded-For`
 
-An attacker can manipulate the `X-Forwarded-For` header to bypass IP-based access controls. This header is often used by proxies to track the originating IP address of a client. However, if a proxy treats this header as hop-by-hop and forwards it without proper validation, an attacker can spoof their IP address.
+An attacker can manipulate the `X-Forwarded-For` header to bypass IP-based access controls. This header is often used by proxies to track the originating IP address of a client. However, if a proxy treats this header as hop-by-hop and forwards it without proper validation, an attacker can spoof their IP address.<sup>[[1]](#references)</sup>
 
 **Attack Scenario:**
 
@@ -31,14 +31,18 @@ An attacker can manipulate the `X-Forwarded-For` header to bypass IP-based acces
 
 ### Cache Poisoning via Hop-by-Hop Header Injection
 
-If a cache server incorrectly caches content based on hop-by-hop headers, an attacker could inject malicious headers to poison the cache. This would serve incorrect or malicious content to users requesting the same resource.
+If a cache server incorrectly caches content based on hop-by-hop headers, an attacker could inject malicious headers to poison the cache. This would serve incorrect or malicious content to users requesting the same resource.<sup>[[1]](#references)</sup>
 
 **Attack Scenario:**
 
 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`).
 2. The poorly configured cache server does not remove the hop-by-hop header and caches the response specific to the attacker's session.
 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.
 
+## References
+
+- [1] [Abusing HTTP hop-by-hop request headers](https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers)
+
 {{#include ../banners/hacktricks-training.md}}
 
 

src/pentesting-web/client-side-path-traversal.md

@@ -26,16 +26,16 @@ Typical sinks (where the traversal lands):
 
 ### Example findings
 
-- In [**this writeup**](https://erasec.be/blog/client-side-path-manipulation/), it was possible to **change the invite URL** so it would end up **canceling a card**.
-- In [**this writeup**](https://mr-medi.github.io/research/2022/11/04/practical-client-side-path-traversal-attacks.html), it was possible to combine a **client side path traversal via CSS** (it was possible to change the path where a CSS resource was loaded from) with an **open redirect** to load the CSS resource from an **attacker controlled domain**.
-- In [**this writeup**](https://blog.doyensec.com/2024/07/02/cspt2csrf.html), it's possible to see a technique on how to abuse CSPT **to perform a CSRF attack**. This is done by **monitoring all the data** that an attacker can control (URL path, parameters, fragment, data injected in the DB...) **and the sinks** this data ends (requests being performed).
+- In [**this writeup**](https://erasec.be/blog/client-side-path-manipulation/), it was possible to **change the invite URL** so it would end up **canceling a card**.<sup>[[6]](#references)</sup>
+- In [**this writeup**](https://mr-medi.github.io/research/2022/11/04/practical-client-side-path-traversal-attacks.html), it was possible to combine a **client side path traversal via CSS** (it was possible to change the path where a CSS resource was loaded from) with an **open redirect** to load the CSS resource from an **attacker controlled domain**.<sup>[[7]](#references)</sup>
+- In [**this writeup**](https://blog.doyensec.com/2024/07/02/cspt2csrf.html), it's possible to see a technique on how to abuse CSPT **to perform a CSRF attack**. This is done by **monitoring all the data** that an attacker can control (URL path, parameters, fragment, data injected in the DB...) **and the sinks** this data ends (requests being performed).<sup>[[8]](#references)</sup>
   - Check [**this browser extension**](https://addons.mozilla.org/en-US/firefox/addon/eval-villain/) to monitor that.
   - Check this [**CSPT playground**](https://github.com/doyensec/CSPTPlayground) to try the technique.
   - Check [**this tutorial**](https://blog.doyensec.com/2024/12/03/cspt-with-eval-villain.html) on how to use the browser extension in the playground.
 
 ## CSPT-assisted web cache poisoning/deception
 
-CSPT can be chained with extension-based CDN caching to exfiltrate sensitive JSON leaked by authenticated API calls:
+CSPT can be chained with extension-based CDN caching to exfiltrate sensitive JSON leaked by authenticated API calls:<sup>[[1]](#references)</sup>
 
 - A frontend concatenates user-controlled input into an API path and attaches authentication headers in fetch/XHR.
 - By injecting dot-segments (../) you can retarget the authenticated request to a different endpoint on the same origin.
@@ -54,7 +54,7 @@ See details and mitigations in the Cache Deception page: [Cache Poisoning and Ca
 
 ### Passive discovery with intercepting proxies
 
-- **Correlate sources/sinks automatically**: the [CSPT Burp extension](https://github.com/doyensec/CSPTBurpExtension) parses your proxy history, clusters parameters that are later reflected inside other requests’ paths, and can reissue proof-of-concept URLs with canary tokens to confirm exploitable traversals. After loading the JAR, set the `Source Scope` to client parameters (e.g., `id`, `slug`) and the `Sink Methods` to `GET, POST, DELETE` so the extension highlights dangerous request builders. You can export all suspect sources with an embedded canary to validate them in bulk.
+- **Correlate sources/sinks automatically**: the [CSPT Burp extension](https://github.com/doyensec/CSPTBurpExtension) parses your proxy history, clusters parameters that are later reflected inside other requests’ paths, and can reissue proof-of-concept URLs with canary tokens to confirm exploitable traversals. After loading the JAR, set the `Source Scope` to client parameters (e.g., `id`, `slug`) and the `Sink Methods` to `GET, POST, DELETE` so the extension highlights dangerous request builders. You can export all suspect sources with an embedded canary to validate them in bulk.<sup>[[5]](#references)</sup>
 - **Look for double-URL-decoding**: while browsing with Burp or ZAP, watch for `/api/%252e%252e/` patterns that get normalized by the frontend before hitting the network—these usually show up as base64-encoded JSON bodies referencing route state and are easy to overlook without an automated scanner.
 
 ### Instrumenting SPA sinks manually
@@ -84,7 +84,7 @@ Dropping a short snippet in DevTools helps surface hidden traversals while you i
 
 ## Recent case studies (2025)
 
-- **Grafana OSS CVE-2025-4123/6023 (v11.5.0+)** – A traversal gadget inside `/public/plugins/` let attackers smuggle `../../` into the plugin asset loader, chain it with Grafana’s open redirect, and force victims to load attacker-controlled plugin bundles. When anonymous dashboards were enabled, a crafted URL such as `https://grafana.example.com/public/plugins/../../../../..//evil.com/poc/module.js` resulted in the browser executing remote JavaScript; if the Image Renderer plugin was installed, the same primitive could be flipped into SSRF by redirecting rendering requests toward internal hosts. Always test plugin asset paths, anonymous dashboards, and renderer endpoints together because a single traversal often gives you both XSS and SSRF angles.
+- **Grafana OSS CVE-2025-4123/6023 (v11.5.0+)** – A traversal gadget inside `/public/plugins/` let attackers smuggle `../../` into the plugin asset loader, chain it with Grafana’s open redirect, and force victims to load attacker-controlled plugin bundles. When anonymous dashboards were enabled, a crafted URL such as `https://grafana.example.com/public/plugins/../../../../..//evil.com/poc/module.js` resulted in the browser executing remote JavaScript; if the Image Renderer plugin was installed, the same primitive could be flipped into SSRF by redirecting rendering requests toward internal hosts. Always test plugin asset paths, anonymous dashboards, and renderer endpoints together because a single traversal often gives you both XSS and SSRF angles.<sup>[[4]](#references)</sup>
 
 ## Payload cookbook
 
@@ -97,10 +97,13 @@ Dropping a short snippet in DevTools helps surface hidden traversals while you i
 
 ## References
 
-- [Cache Deception + CSPT: Turning Non Impactful Findings into Account Takeover](https://zere.es/posts/cache-deception-cspt-account-takeover/)
-- [CSPT overview by Matan Berson](https://matanber.com/blog/cspt-levels/)
-- [PortSwigger: Web Cache Deception](https://portswigger.net/web-security/web-cache-deception)
-- [Grafana CVE-2025-4123 Chained Path Traversal + Open Redirect Analysis](https://www.cve.news/cve-2025-4123/)
-- [Doyensec CSPT Burp Extension](https://github.com/doyensec/CSPTBurpExtension)
+- [1] [Cache Deception + CSPT: Turning Non Impactful Findings into Account Takeover](https://zere.es/posts/cache-deception-cspt-account-takeover/)
+- [2] [CSPT overview by Matan Berson](https://matanber.com/blog/cspt-levels/)
+- [3] [PortSwigger: Web Cache Deception](https://portswigger.net/web-security/web-cache-deception)
+- [4] [Grafana CVE-2025-4123 Chained Path Traversal + Open Redirect Analysis](https://www.cve.news/cve-2025-4123/)
+- [5] [Doyensec CSPT Burp Extension](https://github.com/doyensec/CSPTBurpExtension)
+- [6] [Client-Side Path Manipulation (erasec)](https://erasec.be/blog/client-side-path-manipulation/)
+- [7] [Practical Client-Side Path Traversal Attacks (mr-medi)](https://mr-medi.github.io/research/2022/11/04/practical-client-side-path-traversal-attacks.html)
+- [8] [CSPT2CSRF (Doyensec)](https://blog.doyensec.com/2024/07/02/cspt2csrf.html)
 
 {{#include ../banners/hacktricks-training.md}}