Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0006075 [Resin] major always 07-27-17 03:28 11-21-17 09:43
Reporter stbu View Status public  
Assigned To ferg
Priority normal Resolution fixed  
Status closed   Product Version 4.0.53
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?
Additional Information
Attached Files

- Relationships

- 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.
 

- Issue History
Date Modified Username Field Change
07-27-17 03:28 stbu New Issue
07-27-17 03:28 stbu Issue Monitored: stbu
08-08-17 13:42 ferg Note Added: 0006777
08-08-17 13:42 ferg Assigned To  => ferg
08-08-17 13:42 ferg Status new => closed
08-08-17 13:42 ferg Resolution open => no change required
08-08-17 14:54 ferg Status closed => feedback
08-08-17 14:54 ferg Resolution no change required => reopened
08-08-17 14:54 ferg Note Added: 0006778
08-09-17 16:01 ferg Note Added: 0006779
08-09-17 16:01 ferg Status feedback => closed
08-09-17 16:01 ferg Resolution reopened => fixed
08-09-17 16:01 ferg Fixed in Version  => 4.0.55
11-21-17 09:43 ferg Fixed in Version 4.0.55 => 4.0.54


Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
34 total queries executed.
28 unique queries executed.
Powered by Mantis Bugtracker