|Anonymous | Login | Signup for a new account||05-31-2023 13:19 PDT|
|Main | My View | View Issues | Change Log | Docs|
|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|
|Summary||0006075: Vulnerable to Web Cache Deception Attack|
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:
The URL handling of Caucho Resin works in a way that is required by this attack and should be avoided.
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.
For example this request will serve the content of reference.xtp and not return a 404 for the 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:
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.
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?
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).
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" -->
Added <resin:IfPathInfo>. If the value attribute is null, defaults to a not-null check.
|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.