read only mode?

[ChadDavis <ch...@gmail.com>]

I'm building a system where users can customize their site's look and
feel by uploading templates that will override the built-in templates.
 I'm trying to explore the security aspects of this right now.  It
seems that the method invocation stuff, property setting, and anything
else that could cause state change on my back end is a threat.  I
would appreciate advise on enumerating the dangerous aspects of the
template language, and then ideas on how to block that stuff.

Is there a way to turn off features of the language?

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: read only mode?

[Nathan Bubna <nb...@gmail.com>]

On Fri, Feb 27, 2009 at 9:35 AM, ChadDavis <ch...@gmail.com> wrote:
> Thanks for the info.  I was planning on using wrapper objects.
>
> The 'users' will be admins of the sites, FYI.  So there will be a
> certain amount of accountability.  I'm more concerned about goof ups.

wrappers are good for this.  then you decide exactly what you trust
them with.  if there are objects you want/need to put in the context
but don't want to write a wrapper for, just restrict them with
SecureUberspector; this does prevent them from being rendered, but it
does prevent them from calling any methods on them.

> As for the Uberspector -- is that supposed to be backup against
> developer error?  I mean, it's at first glance hard to imagine how
> something like SecurityManager would end up in the context.

well, given the other things it restricts by default (Class,
ClassLoader, java.lang.reflect.* etc), yeah, it's unlikely.  but some
people let untrusted 3rd parties write templates.  why take chances in
such cases? :)

> On Fri, Feb 27, 2009 at 10:21 AM, Nathan Bubna <nb...@gmail.com> wrote:
>> For starters, you should definitely use this setting:
>> runtime.introspector.uberspect =
>> org.apache.velocity.util.introspection.SecureUberspector
>>
>> This Uberspect implementation blocks the following packages and
>> classes by default, but you can add more to your velocity.properties
>> if you wish:
>>
>> introspector.restrict.packages = java.lang.reflect
>> introspector.restrict.classes = java.lang.Class
>> introspector.restrict.classes = java.lang.ClassLoader
>> introspector.restrict.classes = java.lang.Compiler
>> introspector.restrict.classes = java.lang.InheritableThreadLocal
>> introspector.restrict.classes = java.lang.Package
>> introspector.restrict.classes = java.lang.Process
>> introspector.restrict.classes = java.lang.Runtime
>> introspector.restrict.classes = java.lang.RuntimePermission
>> introspector.restrict.classes = java.lang.SecurityManager
>> introspector.restrict.classes = java.lang.System
>> introspector.restrict.classes = java.lang.Thread
>> introspector.restrict.classes = java.lang.ThreadGroup
>> introspector.restrict.classes = java.lang.ThreadLocal
>>
>> You should probably read and follow advice in this article:
>> http://wiki.apache.org/velocity/BuildingSecureWebApplications
>>
>> And in general, you should take care not to put any objects into your
>> context that have public methods which can change back-end state.  Use
>> wrapper objects, if necessary.
>>
>> On Fri, Feb 27, 2009 at 8:57 AM, ChadDavis <ch...@gmail.com> wrote:
>>> I'm building a system where users can customize their site's look and
>>> feel by uploading templates that will override the built-in templates.
>>>  I'm trying to explore the security aspects of this right now.  It
>>> seems that the method invocation stuff, property setting, and anything
>>> else that could cause state change on my back end is a threat.  I
>>> would appreciate advise on enumerating the dangerous aspects of the
>>> template language, and then ideas on how to block that stuff.
>>>
>>> Is there a way to turn off features of the language?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: read only mode?

[ChadDavis <ch...@gmail.com>]

Thanks for the info.  I was planning on using wrapper objects.

The 'users' will be admins of the sites, FYI.  So there will be a
certain amount of accountability.  I'm more concerned about goof ups.

As for the Uberspector -- is that supposed to be backup against
developer error?  I mean, it's at first glance hard to imagine how
something like SecurityManager would end up in the context.

On Fri, Feb 27, 2009 at 10:21 AM, Nathan Bubna <nb...@gmail.com> wrote:
> For starters, you should definitely use this setting:
> runtime.introspector.uberspect =
> org.apache.velocity.util.introspection.SecureUberspector
>
> This Uberspect implementation blocks the following packages and
> classes by default, but you can add more to your velocity.properties
> if you wish:
>
> introspector.restrict.packages = java.lang.reflect
> introspector.restrict.classes = java.lang.Class
> introspector.restrict.classes = java.lang.ClassLoader
> introspector.restrict.classes = java.lang.Compiler
> introspector.restrict.classes = java.lang.InheritableThreadLocal
> introspector.restrict.classes = java.lang.Package
> introspector.restrict.classes = java.lang.Process
> introspector.restrict.classes = java.lang.Runtime
> introspector.restrict.classes = java.lang.RuntimePermission
> introspector.restrict.classes = java.lang.SecurityManager
> introspector.restrict.classes = java.lang.System
> introspector.restrict.classes = java.lang.Thread
> introspector.restrict.classes = java.lang.ThreadGroup
> introspector.restrict.classes = java.lang.ThreadLocal
>
> You should probably read and follow advice in this article:
> http://wiki.apache.org/velocity/BuildingSecureWebApplications
>
> And in general, you should take care not to put any objects into your
> context that have public methods which can change back-end state.  Use
> wrapper objects, if necessary.
>
> On Fri, Feb 27, 2009 at 8:57 AM, ChadDavis <ch...@gmail.com> wrote:
>> I'm building a system where users can customize their site's look and
>> feel by uploading templates that will override the built-in templates.
>>  I'm trying to explore the security aspects of this right now.  It
>> seems that the method invocation stuff, property setting, and anything
>> else that could cause state change on my back end is a threat.  I
>> would appreciate advise on enumerating the dangerous aspects of the
>> template language, and then ideas on how to block that stuff.
>>
>> Is there a way to turn off features of the language?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: read only mode?

[Nathan Bubna <nb...@gmail.com>]

For starters, you should definitely use this setting:
runtime.introspector.uberspect =
org.apache.velocity.util.introspection.SecureUberspector

This Uberspect implementation blocks the following packages and
classes by default, but you can add more to your velocity.properties
if you wish:

introspector.restrict.packages = java.lang.reflect
introspector.restrict.classes = java.lang.Class
introspector.restrict.classes = java.lang.ClassLoader
introspector.restrict.classes = java.lang.Compiler
introspector.restrict.classes = java.lang.InheritableThreadLocal
introspector.restrict.classes = java.lang.Package
introspector.restrict.classes = java.lang.Process
introspector.restrict.classes = java.lang.Runtime
introspector.restrict.classes = java.lang.RuntimePermission
introspector.restrict.classes = java.lang.SecurityManager
introspector.restrict.classes = java.lang.System
introspector.restrict.classes = java.lang.Thread
introspector.restrict.classes = java.lang.ThreadGroup
introspector.restrict.classes = java.lang.ThreadLocal

You should probably read and follow advice in this article:
http://wiki.apache.org/velocity/BuildingSecureWebApplications

And in general, you should take care not to put any objects into your
context that have public methods which can change back-end state.  Use
wrapper objects, if necessary.

On Fri, Feb 27, 2009 at 8:57 AM, ChadDavis <ch...@gmail.com> wrote:
> I'm building a system where users can customize their site's look and
> feel by uploading templates that will override the built-in templates.
>  I'm trying to explore the security aspects of this right now.  It
> seems that the method invocation stuff, property setting, and anything
> else that could cause state change on my back end is a threat.  I
> would appreciate advise on enumerating the dangerous aspects of the
> template language, and then ideas on how to block that stuff.
>
> Is there a way to turn off features of the language?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org