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.
해결되었습니다! 솔루션으로 이동.
토픽은 커뮤니티 콘텐츠를 분류하여 관련성 있는 콘텐츠를 찾는 데 도움이 됩니다.
조회 수
답글
좋아요 수
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.
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
조회 수
답글
좋아요 수
We have Server version: Apache/2.4.62 installed, this says was fixed in 2.4.55
조회 수
답글
좋아요 수
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.
조회 수
답글
좋아요 수
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>
조회 수
답글
좋아요 수
You can try "Cache Key Manipulation Plugin"
https://docs.trafficserver.apache.org/en/7.1.x/admin-guide/plugins/cachekey.en.html
조회 수
답글
좋아요 수
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.