[GitHub] [freemarker] ddekany commented on pull request #68: Disable advanced freemarker features

[GitBox <gi...@apache.org>]

ddekany commented on pull request #68:
URL: https://github.com/apache/freemarker/pull/68#issuecomment-646900936


   If you haven't, please read this first:
   https://freemarker.apache.org/docs/app_faq.html#faq_template_uploading_security
   
   As you see, if you can't trust template authors (which is not the situation FreeMarker was originally designed for - think about a better alternative to 2000-s JSP, where you could just have java code in your "templates"), then making templates safe is a lot more work than flipping some configuration settings, unless you are very, very lucky. The most important bit is that people want to call the "legitimate" Java API-s of the objects that were exposed to the template. I'm not talking about `?api` here, but about how "generic" java objects, aka POJO-s, are normally exposed. Like in `user.name` (probably calls `User.getName()`), `users.forRole('admin')`, etc., you utilize that. Then, they will also access the objects that these methods return, and so on, potentially a huge graph of objects. Plus, even when the class of a deliberately exposed POJO is developed, as these domain classes are usually not just for the templates, the developer doesn't constantly consider that any public method they adds will be callable from templates. So, I think, in most real world scenarios, it's not feasible to keep API access under control without whitelisting. The whitelist will be specific to the application, and, of course, it's far from a boolean switch. It's not possible to make a simple safety on/off switch.
   
   Regarding frameworks that doesn't let you configure FreeMarker, yet doesn't care to configure it properly itself. What can I say... they just didn't care then. In any real world project, you will want to configure FreeMarker, even if the security aspect doesn't matter. Given how tricky fencing malicious template authors is (see linked FAQ entry), we have no much chance in forcing security on such a framework.
   
   What can we still do? If we go for extremes, then, we could introduce some static method where you can set up a callback, and where you can modify the new `Configuration` before it's returned from the constructor. But that's a horrible thing to do. That hook will affect all libraries that internally use FreeMarker (in case there happens to be more in the same application), not just the one you intended to target. You could target by look into the stack trace, or via thread local storage, if you are lucky though. You also can't know what settings will the framework set after the constructor, and hence, after your callback. Sure, then we could have an API to capture those setter calls as well, so you can override them... now that starts to be really awkward. Also it can be far from obvious for others, that these hooks exist somewhere, causing these mysterious changes, which can cause lot of confusion. So, I really hate the idea, but that's the most I can imagine for "forcing" security.
   
   So, I'm afraid, realistically, the framework authors, who "own" the `Configuration`, has to care about security, and mostly, about the safety of the data-model. If they they do care about the data-model, probably they will also care about configuring the other aspects (disabling this and that), as that's really the easier part. If they try to do that, and have difficulties, then, like in the recent versions, we may add features to help there. But they have to "opt in".


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org