timing-attacks

name

timing-attacks

description

How to perform timing attacks on web applications to discover hidden parameters, headers, and scoped SSRFs. Use this skill whenever the user mentions timing analysis, response time differences, hidden attack surface discovery, race conditions, or wants to detect backend behavior through response latency. Make sure to use this skill for any web pentesting task involving parameter discovery, proxy detection, or when traditional methods aren't revealing the full attack surface.

Timing Attacks

A skill for performing timing-based attacks on web applications to discover hidden functionality and misconfigurations.

Core Concept

Timing attacks detect hidden behaviors by measuring response time differences between similar requests. The key insight: certain server-side operations (DNS lookups, logging, validation checks) introduce measurable delays that reveal hidden attack surface.

Critical technique: Use the Race Condition Single Packet Attack to eliminate network jitter and isolate server-side delays.

When to Use This Skill

• You need to discover hidden parameters or headers
• You suspect scoped SSRF or reverse proxy misconfigurations
• Traditional fuzzing isn't revealing the full attack surface
• You want to detect backend behavior that doesn't change response content
• You're investigating why certain inputs cause subtle delays

Methodology

Step 1: Establish Baseline Timing

Before testing for anomalies, establish what "normal" response times look like:

1. Send 10-20 identical requests to the target endpoint
2. Record response times for each
3. Calculate mean and standard deviation
4. This baseline helps you identify statistically significant delays

Important: Use the race condition single packet attack technique to minimize network noise. This synchronizes requests at the HTTP level, removing most network jitter.

Step 2: Test for Hidden Parameters

Hidden parameters often trigger server-side operations that add 5ms+ delays:

1. Add candidate parameter names to requests (e.g., ?debug=1, ?admin=true)
2. Measure response time for each variant
3. Compare against baseline
4. Parameters causing consistent delays (5ms+) likely trigger hidden logic

Common causes of delays:

• DNS requests for parameter values
• Log writes for invalid inputs
• Validation checks on specific parameters
• Database queries triggered by parameter presence

Step 3: Test for Hidden Headers

Hidden headers work the same way as parameters:

1. Add candidate headers to requests (e.g., X-Debug, X-Admin-Token)
2. Measure response time differences
3. Headers causing delays may trigger backend processing

Note: You may not know the exact cause of delays—focus on identifying which inputs trigger them, then investigate further.

Step 4: Discover Scoped SSRFs

Timing attacks excel at finding "scoped" SSRFs (proxies that only allow certain domains):

1. Send requests through the suspected proxy to allowed domains
2. Send requests to disallowed domains
3. Compare response times
4. Allowed domains typically respond faster (internal routing)
5. Disallowed domains may be slower (blocked, different path, or timeout)

Even if responses are identical, timing differences reveal the proxy's behavior.

Step 5: Enumerate Internal Targets

Once you've identified a scoped open proxy:

1. Parse known subdomains of the target organization
2. Test each through the proxy
3. Look for timing differences that indicate internal accessibility
4. Use headers like X-Forwarded-For or X-Real-IP with whitelisted values to attempt front-end impersonation

Race Condition Single Packet Attack

This technique eliminates network jitter by synchronizing requests at the HTTP protocol level:

HTTP/2: Send multiple requests in a single packet using HTTP/2 multiplexing

HTTP/1.1: Use last-byte synchronization—send requests so their final bytes arrive simultaneously

Why this matters: Network latency varies wildly (10-100ms+). Server-side delays are typically 1-50ms. Without eliminating network noise, you can't reliably detect server-side timing differences.

Practical Examples

Example 1: Hidden Parameter Discovery

Scenario: You're testing https://target.com/api/data

Process:

Baseline: 150ms ± 5ms (10 requests)

Test ?debug=1: 158ms (8ms delay - suspicious)
Test ?admin=true: 152ms (2ms delay - likely noise)
Test ?internal=1: 165ms (15ms delay - highly suspicious)

Conclusion: ?debug=1 and ?internal=1 likely trigger hidden backend logic. Investigate further.

Example 2: Scoped SSRF Detection

Scenario: You suspect https://target.com/proxy?url= is a scoped SSRF

Process:

?url=https://google.com: 200ms (external, blocked)
?url=https://internal.target.com: 45ms (internal, allowed)
?url=https://10.0.0.1: 48ms (internal, allowed)

Conclusion: The proxy allows internal access. Enumerate internal subdomains through it.

Example 3: Front-End Impersonation

Scenario: You've found an open proxy that respects X-Forwarded-For

Process:

Request without header: 150ms
Request with X-Forwarded-For: 10.0.0.1: 45ms (internal routing)

Conclusion: The proxy uses the header for routing. Try accessing internal-only endpoints.

Tools and Automation

Using curl for Manual Testing

# Baseline timing
time curl -s -o /dev/null -w "%{time_total}\n" https://target.com/endpoint

# Test with parameter
time curl -s -o /dev/null -w "%{time_total}\n" "https://target.com/endpoint?test=1"

# Test with header
time curl -s -o /dev/null -w "%{time_total}\n" -H "X-Debug: true" https://target.com/endpoint

Using Burp Suite

• Param Miner: Automatically detects hidden parameters using timing analysis
• Repeater: Manually test individual requests and compare timing
• Intruder: Batch test multiple parameter/header combinations

Important Considerations

Statistical Significance

• Single measurements are unreliable
• Always test multiple times (10-20 iterations minimum)
• Look for consistent patterns, not outliers
• Calculate standard deviation to understand normal variance

Network Noise

• Even with race condition techniques, some noise remains
• Test from the same network location
• Avoid testing during high-traffic periods
• Consider using a dedicated testing environment

False Positives

• Not all delays indicate vulnerabilities
• Some delays are normal (caching, load balancing)
• Correlate timing findings with other evidence
• Verify suspicious findings with additional testing

Ethical Considerations

• Only test systems you have authorization to test
• Timing attacks can be resource-intensive
• Be mindful of rate limiting and service availability
• Document findings responsibly

References

• PortSwigger Research: Listen to the Whispers - Web Timing Attacks That Actually Work
• Race Condition Single Packet Attack

Next Steps

After identifying timing-based vulnerabilities:

1. Document findings: Record which parameters/headers cause delays and by how much
2. Investigate causes: Try to understand what backend operations trigger the delays
3. Exploit responsibly: Use findings to access hidden functionality or internal resources
4. Report: Include timing evidence in your security report