We have observed this vulnerability on our website built on AEM 6.5, Apache 2.4, cache enabled.
Cache poison via malicious request header
Server/Application Misconfiguration Cache poisoning
A cache poisoning vulnerability has been identified: issue at domain.com
The request header Handlechanges the response and is not part of the cache key, which means that this response is cached and will be served to other users on the site.
https://owasp.org/www-community/attacks/Cache_Poisoning
Anyone came across this? Appreciate any solutions around this.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Updating Apache to 2.4.56 or latest should help with this issue as Apache made a fix for HTTP Request Smuggling/Splitting attack which can be exploited for cache poising.
Reference: https://httpd.apache.org/security/vulnerabilities_24.html
Views
Replies
Total Likes
We have Server version: Apache/2.4.62 installed, this says was fixed in 2.4.55
Views
Replies
Total Likes
Is this report coming from some tool?
Also, if Apache is already updated to a version where the vulnerability is fixed, the next step would be to add request header to the cache keys.
Views
Replies
Total Likes
how can we do this?
our configs:
/conf.d/available_vhosts/aem-site_publish.vhost
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
# Header always add X-Vhost "publish"
Header merge X-Frame-Options SAMEORIGIN "expr=%{resp:X-Frame-Options}!='SAMEORIGIN'"
Header merge X-Content-Type-Options nosniff "expr=%{resp:X-Content-Type-Options}!='nosniff'"
Header always set Cache-Control "public; max-age=604800; immutable"
..
..
/conf.d/cache_headers.conf
<LocationMatch "^/content/dam/.*\.(?i:jpe?g|gif|js|mov|mp4|png|svg|txt|zip|ico|webp|pdf)$">
Header set Cache-Control "max-age=43200,stale-while-revalidate=43200,stale-if-error=43200" "expr=%{REQUEST_STATUS} < 400"
Header set Age 0
</LocationMatch>
Views
Replies
Total Likes
You can try "Cache Key Manipulation Plugin"
https://docs.trafficserver.apache.org/en/7.1.x/admin-guide/plugins/cachekey.en.html
Views
Replies
Total Likes
Thanks @gkalyan for the help!
Updates on the fix:
1. This is not cache poisoning.
2. The error was happening when the site was being called with a manipulated header as "Handle: somestring"
3. While "Handle" is not a standard header and a custom one, we verified that default output instead of a 403 is being shown. The initial analysis was that the default output was being written to and is served from the cache. But we verified it is is neither being written-to-the-server nor served from the dispatcher cache as reported. We tested with dispatcher cache tuned-off; And with no cache also.
The fix we added to dispatcher "/conf.d/available_vhosts/xxx.vhost" file to manage "Handle" header:
..
# Adding Cache-Control
Header always set Cache-Control "public; max-age=604800; immutable"
...
...
<IfModule mod_rewrite.c>
..
# Check for "Handle" header. Return a 403
RewriteCond %{HTTP:Handle} .
RewriteRule ^ - [F]
..
..
With this in place, when the site is called using "Handle: xxx" in the header, returns a 403 instead of serving a default content.
Views
Likes
Replies
Views
Like
Replies