Re: Freemarker and security

Friday, December 10, 2010, 5:49:18 PM, Chris wrote:

>> That's also a possibility, but instead of modifying the tree you
>> should throw an exception saying that this-and-that is not allowed for
>> security reasons. Most certainly you should do this check where
>> FreeMarker just finished building the AST (so it can't be
>> circumvented, accidently or otherwise), so you will have to modifying
>> the source code. If you think you find a solution that could be
>> integrated into the official FreeMarker (like adding a callback here
>> and there), tell us. That would be much better than forking for
>> everyone.
>>
>> Note that contributing require you to sign and post a CLA. However, if
>> you careful not to post any actual source code, but point out where
>> should I add and what kind of callback... then I could do that, and
>> you don't have to wait for 2.3.17, as you could use a nightly build,
>> then switch to 2.3.17 whenever it's released.
>>
>
> I'll work on this. I'm thinking some kind of security filter that you 
> set in the template loader. You could arbitrarily allow or disallow 
> certain constructs.

Note that templates can be created directly from a String (with
?interpret for example), in which case there is no TemplateLoader
involved. The natural place for settings that influence parsing is in
the Configuration. See "tag_syntax" as an example (of horrible coding
from the Java stone age... ;) ). Of course setting the filters on
Configuration level might not be fine-gradient enough. I guess
(without digging into the source code) the proper solution will be
still to put that filter into the Configuration, but this filter would
receive the return value of TemplateLoader.findTemplateSource (or null
if the template is parsed from a String), so it could ease the
restrictions if it recognizes a source that is trusted. It's still a
good question how could you recognize when the template is parsed from
a String which is from a trusted template (like when a trusted
template calls someString?interpret or someString?eval)... To address
that, maybe we can say that templates from a String (null source) is
always trusted, and then you have to be careful to prevent untrusted
templates from using ?interpret or ?eval. (Then hope that the authors
of untrusted can't find a way to inject an arbitrary string into the
?interpret/?eval of the trusted templates... you know, through a
tricky macro call or like.)

> I've no problem signing a contributor agreement if you want to post it
> somewhere.

I will send that in private.

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev