Hi, In short, allowing untrusted users to edit templates is not supported. But, since people do it anyway, 2.3.30 will make an effort to allow doing that with taking far less risk than what people take now. The MemberAccessPolicy feature committed in recent days is the start of that. Actually, you could always just use SimpleObjectWrapper (as the FAQ states), but clearly that's too limiting for what many (most?) people use FreeMarker for. But anyway, I don't believe that a template engine with the complexity of FreeMarker will be ever a good fit for applications where random people can edit templates. If users are accountable in real life for what they did, like they are employees at the client, then probably it will be good enough, but not for use cases where anyone can edit templates. If nothing else, you will be too easily DOS-able then.
As of the blog entry, see this: https://issues.apache.org/jira/browse/FREEMARKER-124 Here I would add that it's likely that the calls used in the blog entry won't work anymore in 2.3.30. I'm a bit uneasy about that, as it's a backward compatibility risk (it won't be just blocking that single method), while it doesn't provide real security. You need a whitelist of what's allowed for that (as opposed to a blacklist), and that's possible to do with MemberAccessPolicy, but I will also provide an implementation to help doing that. Also, in the FAQ: https://freemarker.apache.org/docs/app_faq.html#faq_template_uploading_security On Mon, Dec 23, 2019 at 7:25 PM Siegfried Goeschl < [email protected]> wrote: > Hi folks, > > During my last presentation I was asked about how secure Apache Freemarker > is in the context of user editing their templates - well, hard to say > without knowing the application. > > But I came across an interesting article (see > https://ackcent.com/blog/in-depth-freemarker-template-injection/) where > the authors successfully hacked a CMS based on Apache FreeMarker > > * As far as I know the UNRESTRICTED_RESOLVER is the default? Maybe > ALLOWS_NOTHING_RESOLVER would be a better default? > * Enabling "?api" needs to be enabled by developers which is fine > * Update the "unsafeMethods.properties" according to the article? For the > records "java.lang.Thread.suspend()" is duplicated anyway > > Thanks in advance, > > Siegfried Goeschl > > -- Best regards, Daniel Dekany
