Re: 3.1: Declarative Security Issue

[Paul Ferraro <pm...@columbia.edu>]

Come to think of it, it's ok to leave the "/app" servlet mapping, so 
long as the web.xml includes an eager security constraint...

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>...</web-resource-name>
            <url-pattern>/app</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name></role-name>          <!-- i.e. nobody has access -->
        </auth-constraint>
    </security-constraint>

This way, a developer can still perform a server-side forward or include 
to a "/app" uri.

Paul

Paul Ferraro wrote:

> This is exactly why I did not base my friendly url implementation on 
> servlet filters...
> The web.xml files for my friendly url applications do not include a 
> servlet mapping for /app - only extension (i.e. *.something) mappings 
> for each type of service.
>
> Paul
>
> Howard Lewis Ship wrote:
>
>> I just had a thought.
>>
>> Say you require admin role to access the "/admin" folder of your app.
>>
>> You create a admin/DeleteUser page and think "only admins can access 
>> this".
>>
>> Along comes a hacker with knowledge of Tapestry, and types in the URL:
>>
>> /app?service=external&page=admin/DeleteUser&sp=l101010
>>
>> (or such)
>>
>> Unless there's some interior check inside pageValidate(), this may
>> work even though the user doesn't have the necessary access.
>>
>> Even if it isn't DeleteUser, but just ShowUserCreditCardInfo, this is 
>> not good.
>>
>> It's hard to know where  to put logic for this; the external service
>> will not be able to tell the difference between the two by the time it
>> gets invoked.  In many cases, it is perfectly valid for either URL
>> variation to be used.
>>
>> Just want people to put their thinking caps on.  The very flexibility
>> of Tapestry appears to be biting us here.  Perhaps we need a way to
>> ensure that the path URI matches the page's folder.
>>
>>  
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org