Mantis - Resin
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6075 major always 07-27-17 03:28 11-21-17 09:43
Reporter: stbu Platform:  
Assigned To: ferg OS:  
Priority: normal OS Version:  
Status: closed Product Version: 4.0.53  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 4.0.54  
Summary: 0006075: Vulnerable to Web Cache Deception Attack
Description: Under certain circumstances also Resin seems to be vulnerable to Web Cache Deception Attack due to the URL handling.

Please refer to this link for further information regarding this Attack and how PayPal was affected:
http://omergil.blogspot.de/2017/02/web-cache-deception-attack.html?m=1 [^]


The URL handling of Caucho Resin works in a way that is required by this attack and should be avoided.

<quote-from-omer-gil-link>
Configure the web server so that for pages such as http://www.example.com/home.php/non-existent.css, [^] the web server doesn’t return the content of "home.php" with this URL. Instead, for example, the server should respond with a 404 or 302 response.
</quote-from-omer-gil-link>

For example this request will serve the content of reference.xtp and not return a 404 for the non-existent.css:
http://caucho.com/resin-4.0/reference.xtp/non-existent.css [^]


The other requirements for the attack might be beyond the control of a Resin powered host. For example if using Cloudflare and their Cache in front of Resin.
Please refer also to their blog post regarding this:
https://blog.cloudflare.com/understanding-our-cache-and-the-web-cache-deception-attack/ [^]

<quote-from-cloudflare-link>
Defending Against the Web Cache Deception Attack
The best way to defend against this attack is to ensure that your website isn't so permissive, and never treats requests to nonexistent paths (say, /x/y/z) as equivalent to requests to valid parent paths (say, /x). In the example above, that would mean that requests to /newsfeed/foo or /newsfeed/foo.jpg wouldn't be treated as equivalent to requests to /newsfeed, but would instead result in some kind of error or a redirect to a legitimate page.
</quote-from-cloudflare-link>


Can the URL handling of Caucho Resin be changed to mitigate such attacks or is there maybe a possibility to mitigate this with some kind of a Url rewriting and dispatching Rule like if JspServlet is triggered but the requests file extensions does not match with the url-patters mapped to JspServlet?
Steps To Reproduce:
Additional Information:
Relationships
Attached Files:

Notes
(0006777)
ferg   
08-08-17 13:42   
server/2hl0

Resin's cache-mapping does not make a page cacheable. It only applies a default max-age to a page that's already marked as cacheable (with a ETag or Last-Modified header). In other words, it doesn't work like cloud flare's cache. Resin never caches a page automatically. The servlet/page must actively mark the page as cacheable.

The 404 would be handled by the servlet or JSP. It's perfectly legal for a JSP to have a path-info, which is why getPathInfo() exists. So, Resin itself can't return a 404. The JSP could (or a filter).
(0006778)
ferg   
08-08-17 14:54   
Changed to feature request for rewrite rules:

Would'nt it be possible to use such a NotFound rewrite rule which matches any *.jsp files if there would be a <resin:IfPathInfo> condition that corresponds to request.getPathInfo()

<resin:NotFound regexp=".*\.jsp"> <!-- Matching any requests to a .jsp file extension -->
  <resin:IfPathInfo regexp=".*"> <!-- my idea of this regexp is to trigger true if there is any path-info. Don't know how to specify a regexp value like "not null" -->
</resin:NotFound>
(0006779)
ferg   
08-09-17 16:01   
server/1u50

Added <resin:IfPathInfo>. If the value attribute is null, defaults to a not-null check.