Re: security audit

By the way, two quick notes about the patches I've proposed on velocity-dev 
(response to Nathan's comments).  Appreciate any feedback, as I received none 
from the mostly dormant velocity-dev list.

(1) Avoid executing methods on objects of type Class/ClassLoader, etc.

Nathan make the excellent point that developers need to be able to turn this 
off or on.  I did this using a config property in my proposed patch, with the 
default ON.  (For some reason the patch seems not to have been posted to the 
velocity-dev archives, so I'm going to resend it).  On should be the default, 
as IMHO, 95% of Velocity templates do not have a legitimate reason to call 
methods on these classes (and as a matter of principle, I think that systems 
should generally ship with more stringent security enabled by default),  Those 
generating code can turn this off with a one-liner in the config file.  (But if 
the committers disagree, it's easy to make the default off).

I believe this is a critical issue for Velocity web developers, as the negative 
consequences of allowing a template designer to create any class and call any 
method (like File.delete) are quite severe.  

(2)  Event handler allowing developer to control resource pulled up by #include 
and #parse
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-dev@xxxxxxxxxxxxxxxxxx&msgNo=7781

Nathan suggests this should be a custom directive.  As a contrasting opinion, 
I'd like to see this go into the Velocity core, as it's a generally useful 
capability.  (In the meantime, I've patched my private build of Velocity).  
This patch empowers the causal Velocity developer, solves a critical problem 
for some developers and is 100% backwards compatible.   

Nathan's suggestion of creating a custom directive is complex, undocumented and 
requires knowledge of the Velocity source.  And as I understand it, the old 
versions of #include and #parse would still be available to the template design 
(which might not be what the developer wants).   As a contrast, if a developer 
wishes to have a custom behavior for #include, creating an event handler is 
easy.  Some things you can do with just a couple of lines of code in an event 
handler

-- make an included file be relative to the current template.  (Easier for the 
template designer to understand as this is analogous to HTML href's)
-- when a resource is included from a particular pool of pages (e.g. a user web 
site), pull it from a particular location
-- add user-specific permissions for included files

The last one is the critical need.  The servlet can control whether a logged in 
user has access to the parent resource.  But there is *no current means* for 
the developer to limit access to a included resource by user.  If a template 
designer uses a #include, then all users who can access the parent page can 
access the included file.  Using separate resource configs per user is not 
feasible.  You'd have to instantiate a separate VelocityEngine for every user.  
With 100's of users, this would be 100's of VEs.

As I noted in an earlier email, I have about 600 users who can create web 
templates and upload them into the same resource-space.   Maybe this is a 
special case.  But I'd like to see a simple way for Velocity to offer 
flexibility to the developer on controlling this without making modifications 
to the Velocity source.

Thanks again to Nathan for his comments.  (and for that matter, all his efforts 
on the Velocity Tools).  

WILL






_______________________________________
Forio Business Simulations
Will Glass-Husain
www.forio.com