4166Re: [Cheetahtemplate-discuss] Security (when you're letting just anybody make templates)
- Nov 4, 2007Hi Devin,
I agree with Dirk that Cheetah is far too powerful to expose to untrusted
strangers. However, there is a way to create a locked down version of Cheetah's
syntax and selectively enable only the bits you need and trust. I added this in
Cheetah version 2.0b1. You'll have to disable most directives and the
restricted version of Cheetah you create may not be suitable for your users, but
it will work. You can easily combine it with another markup syntax. I've
personally used it in conjunction with Textile.
Here are the release notes:
- added hooks for filtering / restricting dangerous stuff in cheetah source
code at compile time. These hooks can be used to enable Cheetah template
authoring by untrusted users. See my messages to the email list for more
details. Note, it filters expressions at parse/compile time, unlike Python's old
rexec module which restricted the Python environment at runtime.
# Here are the relevant compiler settings:
# use lower case keys here!!
# lists of directive names, without the start token
'disabledDirectives':, # enable all else by default,
'enabledDirectives':, # or disable everything but these
'disabledDirectiveHooks':, # callable(parser, directiveKey),
# called when a disabled directive is found, prior to raising an exception
'preparseDirectiveHooks':, # callable(parser, directiveKey)
'postparseDirectiveHooks':, # callable(parser, directiveKey)
'preparsePlaceholderHooks':, # callable(parser)
'postparsePlaceholderHooks':, # callable(parser)
# callable(parser, expr, exprType, rawExpr=None, startPos=None)
# exprType is the name of the directive, 'psp', or 'placeholder'.
The key settings are enabledDirectives and expressionFilterHooks. You can
ignore the rest.
You'll also need to see the docstrings and code in Parser.py for
"_applyExpressionFilters(...)" and "_filterDisabledDirectives(...)"
See my comment on Guido's blog for a few simple examples of how to use this stuff:
(scroll down till you find my comment at 12:33 AM, Feb 1st)
On Sun, 4 Nov 2007, Dirk van Oosterbosch, IR labs wrote:
> Hello Devin,
> welcome to mailing lists and welcome to Cheetah in particular!
> Yeah, the problem here really is 'giving random people access'. My feeling is
> Cheetah is way too powerful to ever make this safe.
> Cheetah is intended to be used by teams of developers and designers, who need
> this power and will be able to fix things, if it goes horrible awry.
> Since every expression (EXPR in the documentation, like in #set $var = EXPR
> or #if EXPR #end if), can potentially contain malicious code and can mess
> with the backend of your system, one needs OR to make the available Cheetah
> commands so restricted it is not useful anymore (i.e. forbid use of #if, #for
> etc). OR one needs to make a complicated filter that limits some expressions
> but allows others. I'm not really an expert on security, so others should
> indicate which expressions could be dangarous.
> If you really want to go this route and make Cheetah safe to be used by
> strangers on your website, I think the workflow roughly should be the
> 1. get the cheetah code from the user
> 2. parse it: keep only code within certain allowed #def's (if you don't want
> your users to overwrite your framework stuff)
> 3. parse it for pure python and malicious expressions
> 4. compile the cheetah into html
> forms) out
> 6. send the cleaned html to the browser.
> My conclusion would be that a template system Cheetah is too powerful for use
> by strangers. I would only allow them to use a simple markup language, like
> markdown, perhaps with some extra allowed framework tags, which would be
> replaced by your code. But that's just the paranoid me :-)
> On 4-nov-2007, at 3:27, Devin Jeanpierre wrote:
>> Hey guys, I'm new to mailing lists, and, well, I hope this is the right
>> place to ask a question about Cheetah. Couldn't find an IRC channel (other
>> than freenode's #ctah, which had 1 user online), and I really do want to
>> talk to somebody about Cheetah.
>> I like cheetah, I think it looks really nice, for what I want to do. I've
>> been a member of a few community-creation type sites (two of which have
>> since shut down), where something similar to a templating engine is used to
>> make pages. These templating engines were all in-house, and not very nice.
>> And then I saw Cheetah and other more public templating engines, and I
>> thought to myself how much fun it would be to make a system like that. Not
>> for profit, just for fun, and to let other people play around (because, of
>> course, I'm not just going to throw it away :P).
>> So what happens in a system like that, is that I give a set of templates,
>> each of which gets data depending on which page its on, I suppose, and the
>> end-user can modify them and so on. Problem being that I'm giving random
>> people access to the templating engine, which could be bad. I know that, at
>> the least, there's <%= ... %> and <% ... %> that I would have to get rid
>> of, but I'd like to know if there's anything else? Or, in the worst case,
>> if Cheetah is simply not the right thing to use for this, that I'd also
>> need to hear (and a recommendation to another templating system for it, if
>> any others match the needs, would be wonderful).
>> Thanks for your time.
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>
>> Cheetahtemplate-discuss mailing list
> Dirk van Oosterbosch
> de Wittenstraat 225
> 1052 AT Amsterdam
> the Netherlands
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Cheetahtemplate-discuss mailing list
- << Previous post in topic Next post in topic >>