freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <>
Subject Re: Use TemplateClassResolver.SAFER_RESOLVER by default
Date Sun, 17 May 2020 09:08:03 GMT
It's not backward compatible to change it, but if it would be really useful
to use SAFER_RESOLVER, then we should do it with incompatible_improvements
anyway (and actually it's scheduled to be done with
incompatible_improvements  2.4). However, it's not too useful as far as I
see. If you trust people who write the templates, and so accept that
security wise they have the same power as Java developers, then the
non-restrictive default is not a big deal. If you don't trust them, then
all these light protections are basically useless, and you need to
white-list class members anyway, including the constructors that you want
to be accessible through ?new. I'm not sure if there's an in-between
solution that's good for anything, since you defense is only as strong as
it's weakest point. See also:

Then the question arises, why do we have  SAFER_RESOLVER, and for that
mater, the default blacklisting of some methods (often referred to as the
"unsafe methods") at all? If you ask me now, maybe we shouldn't have those.
When FreeMarker was made, untrusted template weren't considered at all
(apparently). The mindset was to provide an alternative to JSP (the old
one, that didn't even have ${...} yet), and the goal of the separation of
Java code and templates was the separation of the presentation aspect, to
support MVC pattern better. In JSP, back then, having Java code snippets
was the norm, so that wasn't about security either. But as it turns out,
users sometimes think that because you can't enter Java code into templates
(but you can call Java API-s, so it's almost the same), it's somehow a
security barrier as well. As of SAFER_RESOLVER, as far as I remember, some
users were concerned about template authors being able to run arbitrary
commands (cat \etc\passwd, rm -r /stuff, etc.). Again, just like your Java
code can. None the less, make that so easy looked silly for sure. So, I
added SAFER_RESOLVER. So that it takes more will and skill for a template
author to hurt you. Same with blocking attacks published in some blog
entries. But again, if you didn't do all the things in,
then a template author with some persistence and skill will manage to
breach you anyway.

On Sun, May 17, 2020 at 8:41 AM Jacques Le Roux <> wrote:

> Hi,
> After reading
> I wonder
> why we have not TemplateClassResolver.SAFER_RESOLVER[1] used
> by default, like there is:
>      The api_builtin_enabled configuration setting must be set to true.
> Its default is false (at least as of 2.3.22) for not lowering the security
> of
> existing applications.[2]
> Is there a reason?
> Thanks
> Jacques
> [1]
> [2]

Best regards,
Daniel Dekany

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message