Posts
Cache Poisoned Denial of Service Simplified
Suppose someone try to visit a website lets says "davindertutorials.com" than the request go to the server . But what if the website server is placed in US and I am surfing that website from India . Few minutes earlier my friend who is living near to me accessing that same website . So lets says davindertutorials.com server is in US but is taking services from cloudfare. So cloudfare DNS is holding copy of the page requested by me which is accessed by my friend few minutes earlier is saved in the cache of cloudfare.
Whenever a cache receives a request for a resource, it needs to decide whether it has a copy of this exact resource already saved and can reply with that, or if it needs to forward the request to the application server.
Simplified example of this attack :
> GET /index.html HTTP/1.1 > GET /index.html HTTP/1.1
> Host: example.com > Host: evil.com
Identifying whether two requests are trying to load the same resource can be difficult so requiring that the requests match byte-for-byte is not actually possible so Caches tackle this problem using the concept of cache keys – a few specific components of a HTTP request that are taken to fully identify the resource being requested. In the request above, I've highlighted the values included in a typical cache key in orange.
GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/57.0
Accept: */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://google.com/
Cookie: jessionid=xyz;
Connection: close
This means that caches think the following two requests are equivalent, and will happily respond to the second request with a response cached from the first:
GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/57.0
Cookie: language=pl;
Connection: close
GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/57.0
Cookie: language=en;
Connection: close
This means that caches think the following two requests are equivalent, and will happily respond to the second request with a response cached from the first:
So now if you see, attacker have replaced the language in the cache .. so they can also make many other changes as well
To verify that the cache has been poisoned, just load the homepage in a browser and observe the popup.
Whenever a cache receives a request for a resource, it needs to decide whether it has a copy of this exact resource already saved and can reply with that, or if it needs to forward the request to the application server.
Simplified example of this attack :
> GET /index.html HTTP/1.1 > GET /index.html HTTP/1.1
> Host: example.com > Host: evil.com
Identifying whether two requests are trying to load the same resource can be difficult so requiring that the requests match byte-for-byte is not actually possible so Caches tackle this problem using the concept of cache keys – a few specific components of a HTTP request that are taken to fully identify the resource being requested. In the request above, I've highlighted the values included in a typical cache key in orange.
GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/57.0
Accept: */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://google.com/
Cookie: jessionid=xyz;
Connection: close
This means that caches think the following two requests are equivalent, and will happily respond to the second request with a response cached from the first:
GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/57.0
Cookie: language=pl;
Connection: close
GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/57.0
Cookie: language=en;
Connection: close
This means that caches think the following two requests are equivalent, and will happily respond to the second request with a response cached from the first:
So now if you see, attacker have replaced the language in the cache .. so they can also make many other changes as well
To verify that the cache has been poisoned, just load the homepage in a browser and observe the popup.
0 comments:
Post a Comment