DOS via cache poisoning on [developer.mozilla.org]
Categories
(developer.mozilla.org :: Security, enhancement)
Tracking
(Not tracked)
People
(Reporter: frida, Assigned: claas)
Details
Attachments
(4 files)
Link: https://hackerone.com/reports/1976449
Date: 2023-05-07 18:23:40 UTC
By: zhero_
Weakness: Cache Poisoning
Details:
Summary:
Hello, after some research it appears that it is possible for an attacker to perform a DOS attack on the https://developer.mozilla.org page for an indefinite period.
This is possible by adding an X-Forwarded-Host
header and a value causing an error on the back-end side (error 404), the bad configuration of the cache makes it possible to save the response there and to serve it to users visiting the page, making the page completely inaccessible for an indefinite period.
No information about the caching period is available in the response, but it is anyway possible to reinterpret the manipulation indefinitely.
For obvious reasons I performed my tests using a cache-buster - adding a URL parameter as we will see in the POC - so as not to affect the user experience.
Steps To Reproduce:
- Pass your HTTP requests through your preferred proxy
- Go to : https://developer.mozilla.org then - in your proxy - send the request to your repeater
- Add the parameter of your choice to the URL, it will serve as a cache-buster and will not "poison" the site visited by users. In other words, the DOS will only be effective on the URL containing your parameter, you probably know this but let me clarify: this is very important in order not to damage the services.
- Add the following header :
X-Forwarded-Host: XXX
The request ready to send (?my_cache_buster=test
) being my cache-buster :
{F2339007}
Once the request has been sent, the response will - as expected - contain a 404 error. Open another browser in incognito mode, and enter the full URL containing your cache-buster. You should get
Reporter | ||
Comment 1•2 years ago
|
||
Hello Florian,
Can you please take a look?
The below comment from H1 triager describes the issue better:
The cache has some unusually long lifetimes, so you'll have to choose your own cache buster to inspect the behavior.
If I send an unmangled GET request to https://developer.mozilla.org/fr/?cusk=absd, I will get a 200 response and a real page:
{F2357301}
Note that the cache lifetime for this page is 24 hours. All attempts to malform this request by sending bad headers just returns the same page:
{F2357303}
However, if you choose a different cache buster like https://developer.mozilla.org/fr/?cusk=absdh and send a malformed request using the header X-Forwarded-Host: XX
you will get an error:
{F2357309}
And the error will persist if the malformed header is removed:
{F2357311}
The difficulty of this attack, and why it is not considered high risk is that to take a site entirely down, an attacker would have to coordinate attacks targeting all web caches, all webpages that they wish to deny, time the attacks so that their malformed attack is cached and not a legitimate response, and get lucky. If they miss the window, they have to wait another 24 hours to try again. Also, any ops engineer is going to notice a successful attack when the error rate spikes and figure out quickly that there is an issue with the web cache, and clear it. The attacker can continuously send their malicious payloads, but eventually, they will get IP banned. If they have a botnet, the attack might be sustainable for a short time, but now we are getting into the territory of DDoS attacks, which are explicitly out of scope.
Long story short, there needs to be a modification to the web cache to reject caching of error pages to completely block this. This might result in some increased bandwidth bills, but it will prevent the denial of service state.
Please let me know if you have any further questions, as these web cache vulns can be convoluted and pesky.
Reporter | ||
Comment 2•2 years ago
|
||
Reporter | ||
Comment 3•2 years ago
|
||
Reporter | ||
Comment 4•2 years ago
|
||
Reporter | ||
Comment 5•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
•
|
||
We mitigate the issue by removing x-forwarded-host
and forwarded
headers from incoming requests: https://github.com/mdn/yari/pull/8894
Note: We use Google Cloud CDN's negative caching to reduce load on our Cloud Function, which caches HTTP 404 responses for 120 seconds. We only cache successful HTTP 2xx responses for 24 hours.
Assignee | ||
Comment 7•2 years ago
•
|
||
Our mitigation was merged on 2023-05-19 and deployed on 2023-05-20 at ~3am GMT+2.
Reporter | ||
Updated•2 years ago
|
Description
•