freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Le Roux <>
Subject Re: Use TemplateClassResolver.SAFER_RESOLVER by default
Date Sun, 17 May 2020 16:25:17 GMT
Thanks Daniel,

Especially, about the link you provided. I'll double check that!


Le 17/05/2020 à 11:08, Daniel Dekany a écrit :
> 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]

View raw message