Hi Daniel, I guess I need to re-read the FreeMarker documentation and ticket - having said that
* The problem described in the article was less about arbitrary people but someone who hacked through other security issues to become administrator with temple editing rights * The people having that skills usually don't have any interest in starting a DOS attack by messing up templates - there are more valuable things out there ... * I think it is pretty much impossible to make FreeMarker 100% bullet proof (tons of features, a lot of code, arbitrary libraries coming from the application) but at least we can check that this attack does not work any longer * From my understanding - usually there a couple of security vulnerabilites leading to complete data breach :-) Thanks in advance, Siegfried Goeschl > On 23.12.2019, at 22:30, Daniel Dekany <[email protected]> wrote: > > 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
