5 ms·

An origin error (i.e. 5XX) is okay to be cached for a while. But a 400 is an error in the request so it should never be cached, ever. I guess that's the point o

An origin error (i.e. 5XX) is okay to be cached for a while. But a 400 is an error in the request so it should never be cached, ever. I guess that's the point of the article, I'm very surprised that CloudFront caches 400s. 404s could be cached, I think, but it's a risky one.

GhettoMaestro 7y ago
You probably know this already, but if you cache 404s you should have a way to purge all cached 404 entries when you do a content push.
sp332 7y ago
I don't understand the problem. If there's something wrong with the request, why expect a different response if the same request is sent again?
- Karunamon 7y ago
  The error could be (and I'd say, usually is) transient, i.e you hit a page and something is broken, you reload and then it's fixed. Real-life example I'm familiar with: Content being served from a busy NAS that buckled under load. You'll have some requests time out with 504s, some return 500s, some that make the files appear missing and so you get 404s. I know, braindead design that shouldn't happen, but it does happen.
- cestith 7y ago
  They're caching the resource based on URI only or on HTTP method and URI only is the problem. If you're caching 400 (which many people have noted is against the RFC and can be troublesome) then you need to make sure you're only caching it for a matching request. If I send a poisoned header and you cache a 400 for my full request including that poisoned header, then that's one thing. If I send a poisoned header and you cache a 400 for all accesses to that URI whether or not they include the header that caused it to be a bad request, that's vulnerable to this BS.
cestith 7y ago
Theoretically if you cache based on the full header other than request time being identical, you could even get away with breaking the RFC and caching a 400 to save the backend generating it again. This specific problem only happens if you do all three of: 1. pass the troublesome header through, 2. cache the 400, 3. treat a new request to the same resource without the poisoned header as if it was the same as the one with the poisoned header.

GhettoMaestro 7y ago

You probably know this already, but if you cache 404s you should have a way to purge all cached 404 entries when you do a content push.

sp332 7y ago

I don't understand the problem. If there's something wrong with the request, why expect a different response if the same request is sent again?

Karunamon 7y ago
The error could be (and I'd say, usually is) transient, i.e you hit a page and something is broken, you reload and then it's fixed. Real-life example I'm familiar with: Content being served from a busy NAS that buckled under load. You'll have some requests time out with 504s, some return 500s, some that make the files appear missing and so you get 404s. I know, braindead design that shouldn't happen, but it does happen.
cestith 7y ago
They're caching the resource based on URI only or on HTTP method and URI only is the problem. If you're caching 400 (which many people have noted is against the RFC and can be troublesome) then you need to make sure you're only caching it for a matching request. If I send a poisoned header and you cache a 400 for my full request including that poisoned header, then that's one thing. If I send a poisoned header and you cache a 400 for all accesses to that URI whether or not they include the header that caused it to be a bad request, that's vulnerable to this BS.

cestith 7y ago

Theoretically if you cache based on the full header other than request time being identical, you could even get away with breaking the RFC and caching a 400 to save the backend generating it again. This specific problem only happens if you do all three of: 1. pass the troublesome header through, 2. cache the 400, 3. treat a new request to the same resource without the poisoned header as if it was the same as the one with the poisoned header.