timing-attacks.md (7633B)
1 --- 2 title: "Timing Attacks" 3 section: "Web Pentesting" 4 sectionSlug: "pentesting-web" 5 sourcePath: "src/pentesting-web/timing-attacks.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/timing-attacks.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # Timing Attacks 14 15 > [!WARNING] 16 > For obtaining a deep understanding of this technique check the original report from [https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work](https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work)<sup>[[1]](#references)</sup> 17 18 ## Basic Information 19 20 The goal of a timing attack is to answer difficult questions or discover hidden functionality by **measuring consistent response-time differences between almost identical requests**. 21 22 Traditionally this was very hard because the interesting server-side signal was drowned in network jitter and server noise. However, after the [**single-packet / synchronized-request techniques**](/hacktricks/pentesting-web/race-condition#http-2-single-packet-attack-vs.-http-1.1-last-byte-synchronization), it became practical to remove most transport noise from the equation and isolate tiny **server-side timing deltas**.<sup>[[1]](#references)</sup> 23 24 This page is focused on **server-side web timing oracles**. For **browser-side / cross-origin timing leaks** check [XS-Search / XS-Leaks](/hacktricks/pentesting-web/xs-search/overview). 25 26 ## Making Timing Attacks Practical 27 28 A modern workflow is usually:<sup>[[1]](#references)</sup> 29 30 1. Build two requests that differ in **exactly one hypothesis** (header present/absent, valid/invalid hostname, duplicated parameter, valid/invalid structured payload, etc.). 31 2. Send both requests with the **same connection and the same release point** so the network path is shared. 32 3. **Alternate the order** of the pair to avoid bias caused by sticky ordering or server-side queue effects. 33 4. Repeat enough times to compare **paired deltas / medians**, not single measurements. 34 5. Tune the probe so one branch forces extra work such as **DNS resolution, cache misses, parsing, validation, logging, deserialization, or a backend fetch**. 35 36 Useful notes: 37 38 - Timing attacks are much easier when you can create a **slow path on demand** instead of waiting for a naturally large delay. 39 - If you need the synchronization internals, HTTP/1.1 last-byte sync, HTTP/2 single-packet, or HTTP/3 last-frame sync, check [the race-condition page](/hacktricks/pentesting-web/race-condition). 40 - Browser caches, proxy caches, DNS caches, and rate limits can all distort results. Sometimes that is noise; sometimes that is the **oracle**. 41 42 ## Discoveries 43 44 ### Hidden Attack Surface 45 46 Timing is excellent for discovering **hidden parameters, headers, cookies, or routes** even when the visible response looks identical. 47 48 In the PortSwigger research, simply adding the right hidden input changed the timing by about **5ms**, which was enough to identify functionality that was otherwise invisible. This is now a natural fit for **Param Miner**.<sup>[[1]](#references)</sup> 49 50 These time differences may appear because: 51 52 - A **DNS lookup** is triggered. 53 - A **different cache key** is used, turning a cache hit into a miss. 54 - A hidden value reaches a **validation / parsing path**. 55 - The application writes an **extra log entry** or throws an exception that is not reflected in the body. 56 - A feature flag or internal middleware makes an **extra backend call** only when the parameter/header is recognized. 57 58 Something you need to remember when performing these attacks is that the surface is hidden, so you often detect the **existence of extra server-side logic first**, and only understand the root cause afterwards. 59 60 ### Server-Side Injection Oracles 61 62 Timing is also useful for vulnerabilities where the application **parses attacker-controlled data server-side**, but the error or output is redacted.<sup>[[1]](#references)</sup> 63 64 - **Blind JSON injection**: if a payload that becomes valid/invalid JSON changes the response time, something downstream is probably parsing it even if the error message is masked. 65 - **Blind server-side parameter pollution**: payloads using duplicated parameters, `%26`, `%23`, or delimiter confusion may alter an internal request. Even if the downstream response is hidden, the extra parsing / error-handling work can still leak via timing. 66 - **Classic sleep-based bugs** are only one case. Timing also helps with injections that do **not** give you a direct `sleep()` primitive but still take different code paths. 67 68 Once you confirm that timing is exposing internal parsing, move to the more specific exploitation pages instead of overloading this one: 69 70 [Parameter Pollution](/hacktricks/pentesting-web/parameter-pollution) 71 72 ### Reverse Proxy Misconfigurations 73 74 Timing is especially powerful for finding **scoped SSRFs** and other reverse-proxy mistakes where the application behaves the same externally, but the backend does extra work only for allowed destinations.<sup>[[1]](#references)</sup> 75 76 Just checking the time difference when an **allowed domain** is used versus when a **disallowed domain** is used can reveal that you found an open proxy even if the HTTP response looks identical. 77 78 A very practical pattern is: 79 80 - First request to `foo.example.com` is slower because of **DNS resolution**. 81 - Second request to the same hostname is faster because of **DNS caching**. 82 - Invalid labels or non-whitelisted suffixes may be rejected faster, giving you a baseline for **input validation** versus **actual outbound resolution**. 83 84 Once a scoped open proxy is discovered, you can often pivot into: 85 86 - **Finding internal targets** by replaying known subdomains or internal naming patterns through the proxy. 87 - **Firewall bypass** by reaching restricted subdomains through the proxy path instead of from the Internet. 88 - **Hidden destination discovery** when some internal-only names never resolve publicly but still produce a timing delta through the proxy. 89 - **Front-end rule bypass** when a public entry point can be coerced into routing traffic to an internal application. 90 - **Front-end impersonation** when the proxy forwards trusted headers such as `X-Forwarded-For`, `X-Real-IP`, or deployment-specific service headers to the backend. 91 92 Once you find that kind of proxy behaviour, combine it with the methodology from [SSRF](/hacktricks/pentesting-web/ssrf-server-side-request-forgery/overview), [HTTP Request Smuggling](/hacktricks/pentesting-web/http-request-smuggling/overview), and hidden parameter discovery. 93 94 ## Useful Tooling 95 96 - **Param Miner**: good for timing-based discovery of hidden parameters/headers and for proxy-oriented timing checks. 97 - **Turbo Intruder**: the timing templates alternate request order, repeat paired probes many times, and let you use cache-busting payloads such as `$randomplz` when needed. 98 - **Burp Repeater - Send group in parallel**: great for quick proof-of-concept testing when you already know the two branches you want to compare. 99 - **PacketSprinter**: useful when you want a UI around grouped parallel HTTP/2 requests and an easier way to compare synchronized responses side by side.<sup>[[2]](#references)</sup> 100 101 ## References 102 103 - [1] [Listen to the whispers: web timing attacks that actually work - PortSwigger Research](https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work) 104 - [2] [PacketSprinter - GitHub repository](https://github.com/richeeta/PacketSprinter)