You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Ulrich Stärk <ul...@spielviel.de> on 2010/01/19 11:26:27 UTC
Rationale behind the pathPattern regex in the RegexAuthorizer contribution
What was the rationale behind not allowing dots in the path part of the URL and additional dots in
the filename?
Are there any objections against allowing them?
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rationale behind the pathPattern regex in the RegexAuthorizer
contribution
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 19 Jan 2010 18:21:06 -0200, Ulrich Stärk <ul...@spielviel.de> wrote:
> I see. So all we want to forbid is two consecutive dots in the path
> part, i.e. before the last /, right?
Right! :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
Coordenador e professor da Especialização em Engenharia de Software com
Ênfase em Java da Faculdade Pitágoras
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Sócio, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rationale behind the pathPattern regex in the RegexAuthorizer
contribution
Posted by Christian Riedel <ch...@gmx.net>.
I had a quick look on the AssetProtectionDispatcher.
How about adding these two lines (maybe with a better regex)...
// given that
String path =
"/path/to/available/resource/../../../../path/to/secure/resource ";
while(path.contains("../")) {
path =
path.replaceFirst("/*?[0-9a-zA-Z\\$\\-\\_\\.\\+\\!\\*\\'\\(\\)\\,]*?/\\.\\.",
"");
}
between line 56 and 57?
:)
Am 19.01.10 23:38, schrieb Robert Zeigler:
> That's definitely a good way to go about it, and I considered it, but
> the overhead of resolving it (you have to resolve to an asset, and
> then resolve the asset to the physical file) was a concern for me.
>
> Robert
>
> On Jan 19, 2010, at 1/194:24 PM , Christian Riedel wrote:
>
>> Or you could just resolve the relative path to an absolute path and
>> apply the existing rule for /path/to/secure/resource?
>>
>> Am 19.01.10 21:21, schrieb Ulrich Stärk:
>>> I see. So all we want to forbid is two consecutive dots in the path
>>> part, i.e. before the last /, right?
>>>
>>> Uli
>>>
>>> On 19.01.2010 18:45 schrieb Robert Zeigler:
>>>> To avoid attempts at circumventing restrictions via relative path
>>>> specifications:
>>>> /path/to/available/resource/../../../../path/to/secure/resource
>>>>
>>>> Some (most? all?) browsers will kindly get rid of the relative path
>>>> reference from the request, but it's certainly possible via, eg, curl,
>>>> wget, etc. to craft such a request. Since we're not actually resolving
>>>> the asset and determining the absolute location, only looking at the
>>>> requested path via regex, it's prudent to deter such attempts.
>>>>
>>>> Robert
>>>>
>>>> On Jan 19, 2010, at 1/194:26 AM , Ulrich Stärk wrote:
>>>>
>>>>> What was the rationale behind not allowing dots in the path part of
>>>>> the URL and additional dots in the filename?
>>>>>
>>>>> Are there any objections against allowing them?
>>>>>
>>>>> Uli
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rationale behind the pathPattern regex in the RegexAuthorizer contribution
Posted by Robert Zeigler <ro...@scazdl.org>.
That's definitely a good way to go about it, and I considered it, but
the overhead of resolving it (you have to resolve to an asset, and
then resolve the asset to the physical file) was a concern for me.
Robert
On Jan 19, 2010, at 1/194:24 PM , Christian Riedel wrote:
> Or you could just resolve the relative path to an absolute path and
> apply the existing rule for /path/to/secure/resource?
>
> Am 19.01.10 21:21, schrieb Ulrich Stärk:
>> I see. So all we want to forbid is two consecutive dots in the path
>> part, i.e. before the last /, right?
>>
>> Uli
>>
>> On 19.01.2010 18:45 schrieb Robert Zeigler:
>>> To avoid attempts at circumventing restrictions via relative path
>>> specifications:
>>> /path/to/available/resource/../../../../path/to/secure/resource
>>>
>>> Some (most? all?) browsers will kindly get rid of the relative path
>>> reference from the request, but it's certainly possible via, eg,
>>> curl,
>>> wget, etc. to craft such a request. Since we're not actually
>>> resolving
>>> the asset and determining the absolute location, only looking at the
>>> requested path via regex, it's prudent to deter such attempts.
>>>
>>> Robert
>>>
>>> On Jan 19, 2010, at 1/194:26 AM , Ulrich Stärk wrote:
>>>
>>>> What was the rationale behind not allowing dots in the path part of
>>>> the URL and additional dots in the filename?
>>>>
>>>> Are there any objections against allowing them?
>>>>
>>>> Uli
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rationale behind the pathPattern regex in the RegexAuthorizer
contribution
Posted by Christian Riedel <ch...@gmx.net>.
Or you could just resolve the relative path to an absolute path and
apply the existing rule for /path/to/secure/resource?
Am 19.01.10 21:21, schrieb Ulrich Stärk:
> I see. So all we want to forbid is two consecutive dots in the path
> part, i.e. before the last /, right?
>
> Uli
>
> On 19.01.2010 18:45 schrieb Robert Zeigler:
>> To avoid attempts at circumventing restrictions via relative path
>> specifications:
>> /path/to/available/resource/../../../../path/to/secure/resource
>>
>> Some (most? all?) browsers will kindly get rid of the relative path
>> reference from the request, but it's certainly possible via, eg, curl,
>> wget, etc. to craft such a request. Since we're not actually resolving
>> the asset and determining the absolute location, only looking at the
>> requested path via regex, it's prudent to deter such attempts.
>>
>> Robert
>>
>> On Jan 19, 2010, at 1/194:26 AM , Ulrich Stärk wrote:
>>
>>> What was the rationale behind not allowing dots in the path part of
>>> the URL and additional dots in the filename?
>>>
>>> Are there any objections against allowing them?
>>>
>>> Uli
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rationale behind the pathPattern regex in the RegexAuthorizer
contribution
Posted by Ulrich Stärk <ul...@spielviel.de>.
I see. So all we want to forbid is two consecutive dots in the path part, i.e. before the last /, right?
Uli
On 19.01.2010 18:45 schrieb Robert Zeigler:
> To avoid attempts at circumventing restrictions via relative path
> specifications:
> /path/to/available/resource/../../../../path/to/secure/resource
>
> Some (most? all?) browsers will kindly get rid of the relative path
> reference from the request, but it's certainly possible via, eg, curl,
> wget, etc. to craft such a request. Since we're not actually resolving
> the asset and determining the absolute location, only looking at the
> requested path via regex, it's prudent to deter such attempts.
>
> Robert
>
> On Jan 19, 2010, at 1/194:26 AM , Ulrich Stärk wrote:
>
>> What was the rationale behind not allowing dots in the path part of
>> the URL and additional dots in the filename?
>>
>> Are there any objections against allowing them?
>>
>> Uli
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Rationale behind the pathPattern regex in the RegexAuthorizer
contribution
Posted by Dmitry Gusev <dm...@gmail.com>.
Then why not restrict relatives paths only?
Current implementation forbid paths like:
/path/to/file-1.0.0.png
This isn't relative path but it has periods in filename.
On Tue, Jan 19, 2010 at 20:45, Robert Zeigler <ro...@scazdl.org> wrote:
> To avoid attempts at circumventing restrictions via relative path
> specifications:
> /path/to/available/resource/../../../../path/to/secure/resource
>
> Some (most? all?) browsers will kindly get rid of the relative path
> reference from the request, but it's certainly possible via, eg, curl, wget,
> etc. to craft such a request. Since we're not actually resolving the asset
> and determining the absolute location, only looking at the requested path
> via regex, it's prudent to deter such attempts.
>
> Robert
>
>
> On Jan 19, 2010, at 1/194:26 AM , Ulrich Stärk wrote:
>
> What was the rationale behind not allowing dots in the path part of the
>> URL and additional dots in the filename?
>>
>> Are there any objections against allowing them?
>>
>> Uli
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Rationale behind the pathPattern regex in the RegexAuthorizer contribution
Posted by Robert Zeigler <ro...@scazdl.org>.
To avoid attempts at circumventing restrictions via relative path
specifications:
/path/to/available/resource/../../../../path/to/secure/resource
Some (most? all?) browsers will kindly get rid of the relative path
reference from the request, but it's certainly possible via, eg, curl,
wget, etc. to craft such a request. Since we're not actually
resolving the asset and determining the absolute location, only
looking at the requested path via regex, it's prudent to deter such
attempts.
Robert
On Jan 19, 2010, at 1/194:26 AM , Ulrich Stärk wrote:
> What was the rationale behind not allowing dots in the path part of
> the URL and additional dots in the filename?
>
> Are there any objections against allowing them?
>
> Uli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org