Expand my Community achievements bar.

AEM 6.5 on-premise Cache poisoning via malicious request header vulnerability

Avatar

Level 2

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

Topics help categorize Community content and increase your ability to discover relevant content.

7 Replies

Avatar

Community Advisor

@SurenKo 

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

Avatar

Level 2

We have Server version: Apache/2.4.62 installed, this says was fixed in 2.4.55

Avatar

Community Advisor

@SurenKo 

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.

Avatar

Level 2

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>

Avatar

Level 2

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.