AEM 6.5 on-premise Cache poisoning via malicious request header vulnerability | Community
Skip to main content
ksuren
ksuren
Level 3
December 6, 2024
Solved

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

  • December 6, 2024
  • 2 replies
  • 1463 views

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.

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by ksuren

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.

2 replies

gkalyan
Community Advisor and Adobe Champion
gkalyanCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
December 6, 2024

@ksuren 

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

ksuren
ksurenAuthor
Level 3
December 6, 2024

thanks @gkal , will try this.

    ksuren
    ksurenAuthor
    Level 3
    December 6, 2024

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

    ksuren
    ksurenAuthorAccepted solution
    Level 3
    December 10, 2024

    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.

      Terms & ConditionsAccessibility statement

      Loading footer...