Re: Can clients really specify 'layout' parameter in the URL?

2012-01-09 Thread Christopher Schultz
Nathan,

On 1/8/12 2:04 PM, Nathan Bubna wrote:
> The tools.view.servlet.layout.directory property is fairly important
> here, as it is prefixed to layout paths.  i didn't think just slipping
> .. into the path would get Velocity to load things out of that
> directory.  Seems like this isn't anymore risky than allowing third
> parties to use #parse, #inclue or anything else that loads/renders
> templates dynamically.

That's true, but if you never code your templates to use request
/parameters/ as part of a path to #parse or #include, then you are safe.
In this case, the request parameter is used if it's there by
VelocityLayoutServlet: you can't prevent a remote user from selecting
the template because it's part of the servlet.

> So, before we jump to calling this an inherent security flaw.  What is
> your layout directory?

What's *in* it? I have about 10 templates (header.vm, footer.vm,
Default.vm, etc.) in there.

> What is your resource loader configuration?

All defaults in development (where it's reproducible), and these
settings in prod (which is also vulnerable):

resource.loader=webapp
webapp.resource.loader.class=org.apache.velocity.tools.view.servlet.WebappLoader
webapp.resource.loader.cache=true
webapp.resource.loader.path=/

(I think those are roughly the defaults, anyway).

> The resource loaders really ought not be able to load any file either,
> otherwise the VelocityViewServlet itself becomes a risk, right?

Perhaps this is only a problem if the webapp.resource.loader.path=/, but
I believe that is the default configuration.

It's fairly easy to try on your own webapp.

-chris



signature.asc
Description: OpenPGP digital signature


Re: Can clients really specify 'layout' parameter in the URL?

2012-01-09 Thread Nathan Bubna
On Mon, Jan 9, 2012 at 11:00 AM, Christopher Schultz
 wrote:
> Nathan,
>
> On 1/8/12 2:04 PM, Nathan Bubna wrote:
>> The tools.view.servlet.layout.directory property is fairly important
>> here, as it is prefixed to layout paths.  i didn't think just slipping
>> .. into the path would get Velocity to load things out of that
>> directory.  Seems like this isn't anymore risky than allowing third
>> parties to use #parse, #inclue or anything else that loads/renders
>> templates dynamically.
>
> That's true, but if you never code your templates to use request
> /parameters/ as part of a path to #parse or #include, then you are safe.
> In this case, the request parameter is used if it's there by
> VelocityLayoutServlet: you can't prevent a remote user from selecting
> the template because it's part of the servlet.
>
>> So, before we jump to calling this an inherent security flaw.  What is
>> your layout directory?
>
> What's *in* it? I have about 10 templates (header.vm, footer.vm,
> Default.vm, etc.) in there.

is !- in it

i'm just trying to figure out what your
tools.view.servlet.layout.directory setting is.

>> What is your resource loader configuration?
>
> All defaults in development (where it's reproducible), and these
> settings in prod (which is also vulnerable):
>
> resource.loader=webapp
> webapp.resource.loader.class=org.apache.velocity.tools.view.servlet.WebappLoader
> webapp.resource.loader.cache=true
> webapp.resource.loader.path=/
>
> (I think those are roughly the defaults, anyway).
>
>> The resource loaders really ought not be able to load any file either,
>> otherwise the VelocityViewServlet itself becomes a risk, right?
>
> Perhaps this is only a problem if the webapp.resource.loader.path=/, but
> I believe that is the default configuration.

The point is merely that if the servlet is picking templates via url
path, how is that any more secure than picking a layout template via a
param.  Both are meant to be constrained to particular directories and
not allow general file access.  Those constraints ought to be coming
from the resource loader [configuration], not the servlet.

> It's fairly easy to try on your own webapp.at

not at the moment, tomorrow, maybe.

>
> -chris
>

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