You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Will Glass-Husain <wg...@apache.org> on 2005/01/07 02:42:17 UTC
absolute path with fileresourceloader
Hi,
I made a commit this morning, then backed it out regarding
FileResourceLoaderPath.
http://issues.apache.org/bugzilla/show_bug.cgi?id=17379
With a empty template path, any file on the hard drive can be accessed as a
template. I thought this was appealing, as "Why can't my file resource
loader access my files" is a common question for a new Velocity user. It
also simplifies the configuration code for many common application-oriented
uses.
However, there's a clear security issue with this patch. that should at
least be discussed. Here's why I'm not worried
(1) Outside users do not directly provide a template name. In a typical
back-end use this is programmed by the developer. In a web use this comes
from the URL (which can be filtered before sending to Velocity).
(2) If a developer does not want to allow absolute file names, he/she just
needs to configure a template path. (Note that this patch only applies for
cases where the template path is not set).
(3) This doesn't affect any existing code, because all existing uses of
FileResourceLoader set a template path.
Any comments? If this doesn't seem right, I'd be interested in hearing it.
Thanks,
WILL
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: absolute path with fileresourceloader
Posted by Will Glass-Husain <wg...@apache.org>.
Thanks, Claude.
A quick answer to your question, FileResourceLoader contains code that
prevents you from doing ".." outside the template path.
Anyone else have comments on this patch, particularly with regard to
security implications? Geir -- you'd expressed some concern. Can you be
more specific?
Thanks, WILL
----- Original Message -----
From: "Claude Brisson" <cl...@renegat.net>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Friday, January 07, 2005 4:07 AM
Subject: Re: absolute path with fileresourceloader
> Hi
>
> On Thu, 2005-01-06 at 17:42 -0800, Will Glass-Husain wrote:
>> Hi,
>>
>> I made a commit this morning, then backed it out regarding
>> FileResourceLoaderPath.
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=17379
>>
>> With a empty template path, any file on the hard drive can be accessed as
>> a
>> template. I thought this was appealing, as "Why can't my file resource
>> loader access my files" is a common question for a new Velocity user. It
>> also simplifies the configuration code for many common
>> application-oriented
>> uses.
>>
>>
>> However, there's a clear security issue with this patch. that should at
>> least be discussed. Here's why I'm not worried
>>
>> (1) Outside users do not directly provide a template name. In a typical
>> back-end use this is programmed by the developer. In a web use this
>> comes
>> from the URL (which can be filtered before sending to Velocity).
>
> Also, typical web usages now rely on the WebappResourceLoader, don't
> they ?
>
>> (2) If a developer does not want to allow absolute file names, he/she
>> just
>> needs to configure a template path. (Note that this patch only applies
>> for
>> cases where the template path is not set).
>>
>> (3) This doesn't affect any existing code, because all existing uses of
>> FileResourceLoader set a template path.
>>
>> Any comments? If this doesn't seem right, I'd be interested in hearing
>> it.
>
> In fact if I understand correctly the main concern would be a web
> application using a FileResourceLoader with no resource path specified,
> and that just add the prefix of the resources to what is extracted from
> the url. In this case, a user could effectively call urls with lots
> of ../../ inside to see what happens... Well, am I wrong or does this
> security hole already exist in the current version ? The patch does not
> change anything here.
>
> By the way, shoudln't the FileResourceLoader act as a "chroot" (i.e.
> forbid any ../) when a resource path is given ?
>
> Anyway, all there scenarios are the result of bad implementation
> choices.
>
> I'm sure you can go on with the patch.
>
> Moreover, it seems the only solution on windows operating systems to
> give the ability to access any file (because they don't have a '/' root
> path as unix-like systems).
>
> Claude
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: absolute path with fileresourceloader
Posted by Claude Brisson <cl...@renegat.net>.
Hi
On Thu, 2005-01-06 at 17:42 -0800, Will Glass-Husain wrote:
> Hi,
>
> I made a commit this morning, then backed it out regarding
> FileResourceLoaderPath.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=17379
>
> With a empty template path, any file on the hard drive can be accessed as a
> template. I thought this was appealing, as "Why can't my file resource
> loader access my files" is a common question for a new Velocity user. It
> also simplifies the configuration code for many common application-oriented
> uses.
>
>
> However, there's a clear security issue with this patch. that should at
> least be discussed. Here's why I'm not worried
>
> (1) Outside users do not directly provide a template name. In a typical
> back-end use this is programmed by the developer. In a web use this comes
> from the URL (which can be filtered before sending to Velocity).
Also, typical web usages now rely on the WebappResourceLoader, don't
they ?
> (2) If a developer does not want to allow absolute file names, he/she just
> needs to configure a template path. (Note that this patch only applies for
> cases where the template path is not set).
>
> (3) This doesn't affect any existing code, because all existing uses of
> FileResourceLoader set a template path.
>
> Any comments? If this doesn't seem right, I'd be interested in hearing it.
In fact if I understand correctly the main concern would be a web
application using a FileResourceLoader with no resource path specified,
and that just add the prefix of the resources to what is extracted from
the url. In this case, a user could effectively call urls with lots
of ../../ inside to see what happens... Well, am I wrong or does this
security hole already exist in the current version ? The patch does not
change anything here.
By the way, shoudln't the FileResourceLoader act as a "chroot" (i.e.
forbid any ../) when a resource path is given ?
Anyway, all there scenarios are the result of bad implementation
choices.
I'm sure you can go on with the patch.
Moreover, it seems the only solution on windows operating systems to
give the ability to access any file (because they don't have a '/' root
path as unix-like systems).
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org