Security Alert: Don't allow users visiting MVC Views directly

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Security Alert: Don't allow users visiting MVC Views directly

Daniel Dekany
A rather dangerous security hole was discovered in Web applications
with certain components and configuration, which can be exploited
through FreeMarker.

Which systems are affected

Web applications using JSP Model-2 approach to implement MVC (like
older versions of Struts and WebWorks) are POSSIBLY vulnerable if the
templates have a publicly visitable URL (like Having such visitable MVC Views, while is
a bad practice, doesn't make the application vulnerable in itself,
only combined with certain runtime environment settings unrelated to
FreeMarker. No more details will be disclosed until FreeMarker 2.3.19
(expected at the end of February), so users has a chance to secure
their applications (see later how). Even if your system is not
vulnerable, if you have directly visitable templates, you should apply
the fix described below, as similar undiscovered exploits may exist.

This security problem exists regardless of FreeMarker version.
FreeMarker 2.3.19 will have a change to block this exploit in some
cases, but not in all cases.

How to fix the issue

MVC Views should only be callable by the MVC Controller, even
regardless of this security issue. They shouldn't have public URL-s,
since they are internal implementation details. Indeed, most of them
are dysfunctional without the Controller preparing the data-model.

To fix this, add this to WEB-INF/web.xml before </web-app> or
login-config or security-role or env-entry or ejb-ref, whichever comes

       Prevent the visiting of MVC Views from outside the servlet container.
       RequestDispatcher.forward/include should and will still work.
       Removing this may open security holes!
         <web-resource-name>FreeMarker MVC Views</web-resource-name>
         <!-- Nobody is allowed to visit these -->

You have to replace the "*.ftl" pattern inside the "url-pattern" with
the pattern that your FreeMarker view servlet (such as
FreemarkerServlet) is mapped to.

This requires Servlet 2.2 or later, and it always should be checked
that visiting a template directly indeed gives an error (HTTP 403).


   Modern Web application frameworks don't use the request-forwarding
   approach anymore for FreeMarker views. So possibly you can remove
   the related servlet declaration altogether, without breaking the
   application. It happens that it was just left there for no good

Some question that may arise

Q: What can the attacker do?
A: Sorry, no information will be released until 2.3.19.

Q: Why don't you just release all the information now?
A: To give users a chance to secure their systems before that.

Q: But now I don't know if my system is vulnerable!
A: You should apply the "security-constraint" fix regardless.
   Maybe even where you don't use FreeMarker.

Q: Why don't you release 2.3.19 as soon as possible?
A: Because a source code change would expose what the problem is,
   while it wouldn't even give 100% protection.

Q: Is this security issue being actively exploited now?
A: We are not aware of any incidents that use this exploit.

Best regards,
 Daniel Dekany

Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
FreeMarker-devel mailing list
[hidden email]