2 ms·
Akamai wrestles with AWS S3 web cache poisoning bug
- 80x25 4y agoHere's the researcher's write-up of the issue with more details: https://spyclub.tech/2022/12/14/unusual-cache-poisoning-akamai-s3/ https://spyclub.tech/2022/12/14/unusual-cache-poisoning-akam... Interesting research and super useful write-up! My observations: - The characters that enable the Host header field forgery aren't unicode characters. They are a subset of separator characters from ASCII. My guess is that the Akamai parser is trimming the Host header field name and not enforcing the requirements from https://www.rfc-editor.org/rfc/rfc7230#section-5.4 https://www.rfc-editor.org/rfc/rfc7230#section-5.4 after this trim, specifically: A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field or a Host header field with an invalid field-value. Even worse, the last Host header field appears to "win" and be the selected Host header field in the request forwarded to the origin. - The OP does mention that Akamai intends to enable stricter header field parsing in 2023 but that response leaves a lot to be desired. They could probably provide a proactive analysis of a customer's traffic to inform them that they can turn on RFC compliant parsing without impact. Punting this decision to their customers requires their customers to be HTTP experts. If I were an Akamai customer, I would expect them to be my HTTP experts for me.