velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Bubna <nbu...@gmail.com>
Subject Re: read only mode?
Date Fri, 27 Feb 2009 17:50:47 GMT
On Fri, Feb 27, 2009 at 9:35 AM, ChadDavis <chadmichaeldavis@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 <nbubna@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 <chadmichaeldavis@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


Mime
View raw message