Re: Freemarker and security
Daniel Dekany <[email protected]>
| Newsgroups | gmane.comp.web.freemarker.user |
|---|---|
| Message-ID | <[email protected]> |
Thursday, December 9, 2010, 4:47:28 AM, Chris wrote: > We're building an app where untrusted users will be able to create their > own templates. This is a website where users will be able to create > their own websites in a shared environment. The different sites will > share a JVM. > > What are the security risks? I told for several occasions here that FTL (like almost any other template language) was designed to be the part of the application source code, so from a stricter security standpoint it's as dangerous as Java code. And when it comes to security, you should be paranoid, so even without looking into details, I would never dare to let visitors upload templates. Unless of course I can also properly "sandbox" arbitrary Java code they upload, because FreeMarker can only do less... > I looked through the Freemarker template language and did not find much > of concern, though I'm a bit leery of the ways that users might be able > to invoke Java code. There are some ways to do that, if a users really wants that... - The ?new feature, while it only allows the instantiation of TemplateModel-s, is still very dangerous. In 2.3.17 there will be a setting to regulate what one can do with ?new, but until that do NOT ever let potentially malicious users to upload any templates unless you patch FreeMarker to only allow a fixed list of classes to be instantiated with ?new. I'm not kidding. Never ever allow that! To prevent FUD, this is only a concern if somebody lets untrusted users to upload templates (which is already quite a risk). - The data-model... depends on what ObjectWrapper are you using, but with BeansWrapper and its sub-classes (like the DefaultObjectWrapper!), you can access all public methods (with the default setting at least) and JavaBean properies of the exposed object. That's so by design of course. When programmers develop the API-s of the objects, they certainly won't always consider "what if this is called from a template that wasn't written by us". > Can anyone point to specific risks or holes we need to look out for? Apart from the access to Java objects/classes described above: - It's quite easy to implement DOS attacks... just create a sufficiently long loop, or build a huge string in a loop. - The paths specified for #import/#include can possibly reach files that they should not. It depends on the concrete TemplateLoader-s used, but some might can be tricked with tricky paths (like with an escaping that FM doesn't understand but the mechanism for which the TemplateLoader implementation is an adapter for does). Again, the issue is that not even the core TemplateLoader-s were ever professionally reviewed from security standpoint. They certainly protect you well against accidents, but against hackers... I wouldn't trust them. Unless, of course, you write your own TemplateLoader that was carefully designed that way, do some extra checks, etc. > Any advice on how to lock it down so users won't be able to do any > damage outside the context of their own template? I don't believe that using *any* non-trivial template language that wasn't designed especially for this is kind of thing is a wise idea, assuming your users can be malicious. Except, if you can somehow sandbox the templates on a lower level, as I said. User-written FreeMarker templates are certainly fine if the worst the users can do is hacking his/her own computer (i.e. when templates run on the client)... but when they run on the server... I can (and will) fix ?new etc, but it never will be safe enough for me to allow arbitrary users to upload them. It's just too big, and wasn't designed for that. -- Best regards, Daniel Dekany ------------------------------------------------------------------------------ This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com