[T5] Security of files in the classpath

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[T5] Security of files in the classpath

Thiago H de Paula Figueiredo
Hi!

I'm developing a Tapestry 5 application and I was looking at access to  
assets via URLs. I typed http://localhost:8080/assets/tapestry/default.css 
to take a look at T5 default CSS values.

Then I typed http://localhost:8080/assets/hibernate.cfg.xml . . . and it  
showed that file. It's a security flaw.
Is there any measure already implemented against this kind of attack? It  
would be very nice if we could block asset access to files and folders  
through some Tapestry-IoC contribution. ;)

Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Daniel Jue
Hi,  Just don't put configuration resources there.  Here's what I use
(since I wrote it up heheh):

http://wiki.apache.org/tapestry/Tapestry5WhereToStoreConfigurationResources



http://wiki.apache.org/tapestry/Tapestry5WhereToStoreExternalResources



On 7/26/07, Thiago H de Paula Figueiredo <[hidden email]> wrote:

> Hi!
>
> I'm developing a Tapestry 5 application and I was looking at access to
> assets via URLs. I typed http://localhost:8080/assets/tapestry/default.css
> to take a look at T5 default CSS values.
>
> Then I typed http://localhost:8080/assets/hibernate.cfg.xml . . . and it
> showed that file. It's a security flaw.
> Is there any measure already implemented against this kind of attack? It
> would be very nice if we could block asset access to files and folders
> through some Tapestry-IoC contribution. ;)
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Thiago H de Paula Figueiredo
On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue <[hidden email]> wrote:

> Hi,  Just don't put configuration resources there.

I'm not sure you had understood what I've said.

My hibernate.cfg.xml is in /src/main/resources. So it is copied by  
Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And anything in  
the classpath, as far as I can see, is accessible via  
<applicatiourl>/assets. As many frameworks expect their configuration  
files to be in the classpath, I think we have a little, easy to solve  
problem here. :)

Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Chris Lewis-5
I think hat's a legitimate problem. I know in T4 a checksum was
generated by links to assets and then verified by tapestry before
yielding the actual asset (by verifying the sum). However the fact that
you can use the asset service to pull any arbitrary file out of the
classpath, even those that are not declared as assets, seems like a
serious issue. I also would like to know a solution (simply restricting
the service to only declared assets should do, but how?).

chris

Thiago H de Paula Figueiredo wrote:

> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue <[hidden email]>
> wrote:
>
>> Hi,  Just don't put configuration resources there.
>
> I'm not sure you had understood what I've said.
>
> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And anything
> in the classpath, as far as I can see, is accessible via
> <applicatiourl>/assets. As many frameworks expect their configuration
> files to be in the classpath, I think we have a little, easy to solve
> problem here. :)
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Thiago H de Paula Figueiredo
On Thu, 26 Jul 2007 18:18:42 -0300, Chris Lewis  
<[hidden email]> wrote:

> I think hat's a legitimate problem. I know in T4 a checksum was  
> generated by links to assets and then verified by tapestry before  
> yielding the actual asset (by verifying the sum). However the fact that  
> you can use the asset service to pull any arbitrary file out of the  
> classpath, even those that are not declared as assets, seems like a  
> serious issue. I also would like to know a solution (simply restricting  
> the service to only declared assets should do, but how?).

I think there is a simple solution: create a configuration point  
(contribution in Tapestry IoC) to the AssertService (I just guessed the  
name) so you can tell it which files can't be accessed as an asset.

JIRA anyone?

Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Daniel Jue
In reply to this post by Thiago H de Paula Figueiredo
Thiago, my apologies.  You are correct.  I would think this is big a
problem if you can't hide important files from users!

Dan

On 7/26/07, Thiago H de Paula Figueiredo <[hidden email]> wrote:

> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue <[hidden email]> wrote:
>
> > Hi,  Just don't put configuration resources there.
>
> I'm not sure you had understood what I've said.
>
> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And anything in
> the classpath, as far as I can see, is accessible via
> <applicatiourl>/assets. As many frameworks expect their configuration
> files to be in the classpath, I think we have a little, easy to solve
> problem here. :)
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Robert Zeigler

Asset service doesn't really need a configuration point here, imo.
You can already make contributions to services that would allow you  
to implement this sort of content filtering.
For instance, you could contribute a RequestFilter. Alternatively,  
you could contribute a Dispatcher to teh MasterDispatcher service.
Contributions to MasterDispatcher are ordered, so you can contribute  
your "AssetBlockerDispatcher" before the asset service, intercept  
requests to "forbidden" assets,
and respond appropriately.  You could then make your custom  
dispatcher (or request filter) configurable in the manner that you  
desire.
You don't rewrite any of the asset service, you get your content  
filtering, and you can write it as a drop-in module for any new  
projects.

Robert

On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:

> Thiago, my apologies.  You are correct.  I would think this is big a
> problem if you can't hide important files from users!
>
> Dan
>
> On 7/26/07, Thiago H de Paula Figueiredo <[hidden email]> wrote:
>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue  
>> <[hidden email]> wrote:
>>
>> > Hi,  Just don't put configuration resources there.
>>
>> I'm not sure you had understood what I've said.
>>
>> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And  
>> anything in
>> the classpath, as far as I can see, is accessible via
>> <applicatiourl>/assets. As many frameworks expect their configuration
>> files to be in the classpath, I think we have a little, easy to solve
>> problem here. :)
>>
>> Thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Thiago H de Paula Figueiredo
On Thu, 26 Jul 2007 23:20:50 -0300, Robert Zeigler <[hidden email]>  
wrote:

> Asset service doesn't really need a configuration point here, imo.
> You can already make contributions to services that would allow you to  
> implement this sort of content filtering.

I agree up to a point. It's a concern that almost all projects have, so  
the framework could (and should) provide an easy way to solve, be it some  
configuration point in AssetService or another dispatcher provided by  
Tapestry.

Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Chris Lewis-5
In reply to this post by Robert Zeigler
I'm quite new to Tapestry and just 2 days ago have started working with
Tap 5. I realize the two (4 vs 5) are disparately different, but one of
the things nice about the Tap 4 asset service was the checksum feature I
mentioned that would deny access unless the sum in the url matched that
of the file. My newness to Tap may show here, but why can't the asset
service simply ignore requests for files that are not marked (@Asset) as
assets? I mean doesn't a deny-all first and allow explicit exceptions
strategy seem much more sane then providing an open door to the whole
classpath (class bytes included??)?

Robert Zeigler wrote:

>
> Asset service doesn't really need a configuration point here, imo.
> You can already make contributions to services that would allow you to
> implement this sort of content filtering.
> For instance, you could contribute a RequestFilter. Alternatively, you
> could contribute a Dispatcher to teh MasterDispatcher service.
> Contributions to MasterDispatcher are ordered, so you can contribute
> your "AssetBlockerDispatcher" before the asset service, intercept
> requests to "forbidden" assets,
> and respond appropriately.  You could then make your custom dispatcher
> (or request filter) configurable in the manner that you desire.
> You don't rewrite any of the asset service, you get your content
> filtering, and you can write it as a drop-in module for any new projects.
>
> Robert
>
> On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
>
>> Thiago, my apologies.  You are correct.  I would think this is big a
>> problem if you can't hide important files from users!
>>
>> Dan
>>
>> On 7/26/07, Thiago H de Paula Figueiredo <[hidden email]> wrote:
>>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue <[hidden email]>
>>> wrote:
>>>
>>> > Hi,  Just don't put configuration resources there.
>>>
>>> I'm not sure you had understood what I've said.
>>>
>>> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
>>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And
>>> anything in
>>> the classpath, as far as I can see, is accessible via
>>> <applicatiourl>/assets. As many frameworks expect their configuration
>>> files to be in the classpath, I think we have a little, easy to solve
>>> problem here. :)
>>>
>>> Thiago
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Robin Helgelin
On 7/27/07, Chris Lewis <[hidden email]> wrote:
> I'm quite new to Tapestry and just 2 days ago have started working with
> Tap 5. I realize the two (4 vs 5) are disparately different, but one of
> the things nice about the Tap 4 asset service was the checksum feature I
> mentioned that would deny access unless the sum in the url matched that
> of the file. My newness to Tap may show here, but why can't the asset
> service simply ignore requests for files that are not marked (@Asset) as
> assets? I mean doesn't a deny-all first and allow explicit exceptions
> strategy seem much more sane then providing an open door to the whole
> classpath (class bytes included??)?

If someone adds a JIRA issue I'm pretty sure Howard is able to solve
this in the best interests of T5.

--
        regards,
        Robin

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Chris Lewis-5
In reply to this post by Thiago H de Paula Figueiredo
I just tried this on the tap 5 tutorial. Requesting the asset service
via /assests (http://localhost:8080/tapestry-tutorial1/assets/)
basically gives you a classpath listing, much like directory index. I
see log4j.properties and org. I can download the log4j - scary - and can
navigate through the classpath as if it where a filesystem. When I tried
to download class bytes for the Start page class
(http://localhost:8080/tapestry-tutorial1/assets/org/apache/tapestry/tutorial/pages/Start.class),
I get  403 and a message about the digest in the request not matching.
So somewhere in there is some sanity, but why does this not apply to
log4/hibernate/etc configurations (maybe b/c they are text??), and why
does the service allow me to effectively browse the classpath?
Anyway, those are my pokings and findings. It seems like this may be
something left in for debugging but should certainly be fixed.

chris

Thiago H de Paula Figueiredo wrote:

> On Thu, 26 Jul 2007 23:20:50 -0300, Robert Zeigler
> <[hidden email]> wrote:
>
>> Asset service doesn't really need a configuration point here, imo.
>> You can already make contributions to services that would allow you
>> to implement this sort of content filtering.
>
> I agree up to a point. It's a concern that almost all projects have,
> so the framework could (and should) provide an easy way to solve, be
> it some configuration point in AssetService or another dispatcher
> provided by Tapestry.
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Thiago H de Paula Figueiredo
In reply to this post by Robin Helgelin
On Fri, 27 Jul 2007 09:59:16 -0300, Robin Helgelin <[hidden email]>  
wrote:

> If someone adds a JIRA issue I'm pretty sure Howard is able to solve
> this in the best interests of T5.

I have just tried to post but Apache's JIRA threw a NullPointerException .  
. .

Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Daniel Jue
> I have just tried to post but Apache's JIRA threw a NullPointerException .
> . .
That made me laugh.

It seems previous versions had problems with information hiding as well:
https://issues.apache.org/jira/browse/TAPESTRY-281
https://issues.apache.org/jira/browse/TAPESTRY-1175

Reminds me of the old IIS days...classic pentesting fodder.


On 7/27/07, Thiago H de Paula Figueiredo <[hidden email]> wrote:

> On Fri, 27 Jul 2007 09:59:16 -0300, Robin Helgelin <[hidden email]>
> wrote:
>
> > If someone adds a JIRA issue I'm pretty sure Howard is able to solve
> > this in the best interests of T5.
>
> I have just tried to post but Apache's JIRA threw a NullPointerException .
> . .
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Robert Zeigler
In reply to this post by Chris Lewis-5
Couple of comments...
First, the T5 asset service has the md5 feature.  But the default  
implementation, at the moment, only requires md5 hashing for  
the .class files. (So, there's not an open door to the class bytes at  
the moment. ;)
Second, I have a T5 app that should be going live in the next few  
days. So I implemented an extensible AssetProtectorDispatcher.  By  
default, it uses a whitelist strategy, and the default configuration  
will add the various tapestry assets (default.css, grid's components,  
etc.) to the whitelist for you.
You can download it here:
http://www.tapestrycomponents.org/Tassel/app?service=external/ 
ViewComponent&sp=SAssetProtectionDispatcher

Or, if you're a maven user, I've got it in a personal maven repo here:
http://www.saiwai-solutions.com/maven

Cheers.

Robert

On Jul 27, 2007, at 7/277:54 AM , Chris Lewis wrote:

> I'm quite new to Tapestry and just 2 days ago have started working  
> with Tap 5. I realize the two (4 vs 5) are disparately different,  
> but one of the things nice about the Tap 4 asset service was the  
> checksum feature I mentioned that would deny access unless the sum  
> in the url matched that of the file. My newness to Tap may show  
> here, but why can't the asset service simply ignore requests for  
> files that are not marked (@Asset) as assets? I mean doesn't a deny-
> all first and allow explicit exceptions strategy seem much more  
> sane then providing an open door to the whole classpath (class  
> bytes included??)?
>
> Robert Zeigler wrote:
>>
>> Asset service doesn't really need a configuration point here, imo.
>> You can already make contributions to services that would allow  
>> you to implement this sort of content filtering.
>> For instance, you could contribute a RequestFilter. Alternatively,  
>> you could contribute a Dispatcher to teh MasterDispatcher service.
>> Contributions to MasterDispatcher are ordered, so you can  
>> contribute your "AssetBlockerDispatcher" before the asset service,  
>> intercept requests to "forbidden" assets,
>> and respond appropriately.  You could then make your custom  
>> dispatcher (or request filter) configurable in the manner that you  
>> desire.
>> You don't rewrite any of the asset service, you get your content  
>> filtering, and you can write it as a drop-in module for any new  
>> projects.
>>
>> Robert
>>
>> On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
>>
>>> Thiago, my apologies.  You are correct.  I would think this is big a
>>> problem if you can't hide important files from users!
>>>
>>> Dan
>>>
>>> On 7/26/07, Thiago H de Paula Figueiredo <[hidden email]> wrote:
>>>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue  
>>>> <[hidden email]> wrote:
>>>>
>>>> > Hi,  Just don't put configuration resources there.
>>>>
>>>> I'm not sure you had understood what I've said.
>>>>
>>>> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
>>>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And  
>>>> anything in
>>>> the classpath, as far as I can see, is accessible via
>>>> <applicatiourl>/assets. As many frameworks expect their  
>>>> configuration
>>>> files to be in the classpath, I think we have a little, easy to  
>>>> solve
>>>> problem here. :)
>>>>
>>>> Thiago
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Sabine K.
Hi Robert,

How to implement this component? Is it necessary to register the component in the appmodule?

Thx

Sabine


Robert Zeigler wrote
Couple of comments...
First, the T5 asset service has the md5 feature.  But the default  
implementation, at the moment, only requires md5 hashing for  
the .class files. (So, there's not an open door to the class bytes at  
the moment. ;)
Second, I have a T5 app that should be going live in the next few  
days. So I implemented an extensible AssetProtectorDispatcher.  By  
default, it uses a whitelist strategy, and the default configuration  
will add the various tapestry assets (default.css, grid's components,  
etc.) to the whitelist for you.
You can download it here:
http://www.tapestrycomponents.org/Tassel/app?service=external/ 
ViewComponent&sp=SAssetProtectionDispatcher

Or, if you're a maven user, I've got it in a personal maven repo here:
http://www.saiwai-solutions.com/maven

Cheers.

Robert

On Jul 27, 2007, at 7/277:54 AM , Chris Lewis wrote:

> I'm quite new to Tapestry and just 2 days ago have started working  
> with Tap 5. I realize the two (4 vs 5) are disparately different,  
> but one of the things nice about the Tap 4 asset service was the  
> checksum feature I mentioned that would deny access unless the sum  
> in the url matched that of the file. My newness to Tap may show  
> here, but why can't the asset service simply ignore requests for  
> files that are not marked (@Asset) as assets? I mean doesn't a deny-
> all first and allow explicit exceptions strategy seem much more  
> sane then providing an open door to the whole classpath (class  
> bytes included??)?
>
> Robert Zeigler wrote:
>>
>> Asset service doesn't really need a configuration point here, imo.
>> You can already make contributions to services that would allow  
>> you to implement this sort of content filtering.
>> For instance, you could contribute a RequestFilter. Alternatively,  
>> you could contribute a Dispatcher to teh MasterDispatcher service.
>> Contributions to MasterDispatcher are ordered, so you can  
>> contribute your "AssetBlockerDispatcher" before the asset service,  
>> intercept requests to "forbidden" assets,
>> and respond appropriately.  You could then make your custom  
>> dispatcher (or request filter) configurable in the manner that you  
>> desire.
>> You don't rewrite any of the asset service, you get your content  
>> filtering, and you can write it as a drop-in module for any new  
>> projects.
>>
>> Robert
>>
>> On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
>>
>>> Thiago, my apologies.  You are correct.  I would think this is big a
>>> problem if you can't hide important files from users!
>>>
>>> Dan
>>>
>>> On 7/26/07, Thiago H de Paula Figueiredo <thiagohp@gmail.com> wrote:
>>>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue  
>>>> <teamphy6@gmail.com> wrote:
>>>>
>>>> > Hi,  Just don't put configuration resources there.
>>>>
>>>> I'm not sure you had understood what I've said.
>>>>
>>>> My hibernate.cfg.xml is in /src/main/resources. So it is copied by
>>>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And  
>>>> anything in
>>>> the classpath, as far as I can see, is accessible via
>>>> <applicatiourl>/assets. As many frameworks expect their  
>>>> configuration
>>>> files to be in the classpath, I think we have a little, easy to  
>>>> solve
>>>> problem here. :)
>>>>
>>>> Thiago
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Robert Zeigler
Nope. Zero configuration necessary for the basic functionality.
Keep in mind, however, that the default configuration is pretty  
restrictive, since
it is whitelist-based, and the only entries added by default are the  
assets that
come "out of the box" with tapestry (tapestry.css, tapestry.js, etc.).

So, you can either contribute a custom AssetPathAuthorizer
(if you don't like the default whitelist strategy...) or you can  
contribute to the  whitelist authorizer.
For instance, I'm using the jscalendar component (http://
code.google.com/p/tapestry5-jscalendar/
personally using a modified version that is compatible with  
T5.0.5...), so I needed to make the assets it uses
available, so I have something like the following in my app module:

     public static void contributeWhitelistAuthorizer(
             Configuration<String> conf,
             @Symbol("net.keso.ted.jscalendarscript.path") String  
jscalendarPath) {
         conf.add(jscalendarPath +"/calendar-blue.css");
         conf.add(jscalendarPath + "/calendar.js");
         conf.add(jscalendarPath + "/lang/calendar-en.js");
         conf.add(jscalendarPath + "/calendar-setup.js");
         conf.add(jscalendarPath + "/button-image.png");

     }

Robert

PS: Noticed that I didn't mention the maven artifactId, etc. before  
when I mentioned putting it into the maven repo...
groupId: com.saiwaisolutions
artifactId: AssetProtectionDispatcher
version: 0.0.1



On Aug 3, 2007, at 8/32:18 AM , Sabine K. wrote:

>
> Hi Robert,
>
> How to implement this component? Is it necessary to register the  
> component
> in the appmodule?
>
> Thx
>
> Sabine
>
>
>
> Robert Zeigler wrote:
>>
>> Couple of comments...
>> First, the T5 asset service has the md5 feature.  But the default
>> implementation, at the moment, only requires md5 hashing for
>> the .class files. (So, there's not an open door to the class bytes at
>> the moment. ;)
>> Second, I have a T5 app that should be going live in the next few
>> days. So I implemented an extensible AssetProtectorDispatcher.  By
>> default, it uses a whitelist strategy, and the default configuration
>> will add the various tapestry assets (default.css, grid's components,
>> etc.) to the whitelist for you.
>> You can download it here:
>> http://www.tapestrycomponents.org/Tassel/app?service=external/
>> ViewComponent&sp=SAssetProtectionDispatcher
>>
>> Or, if you're a maven user, I've got it in a personal maven repo  
>> here:
>> http://www.saiwai-solutions.com/maven
>>
>> Cheers.
>>
>> Robert
>>
>> On Jul 27, 2007, at 7/277:54 AM , Chris Lewis wrote:
>>
>>> I'm quite new to Tapestry and just 2 days ago have started working
>>> with Tap 5. I realize the two (4 vs 5) are disparately different,
>>> but one of the things nice about the Tap 4 asset service was the
>>> checksum feature I mentioned that would deny access unless the sum
>>> in the url matched that of the file. My newness to Tap may show
>>> here, but why can't the asset service simply ignore requests for
>>> files that are not marked (@Asset) as assets? I mean doesn't a deny-
>>> all first and allow explicit exceptions strategy seem much more
>>> sane then providing an open door to the whole classpath (class
>>> bytes included??)?
>>>
>>> Robert Zeigler wrote:
>>>>
>>>> Asset service doesn't really need a configuration point here, imo.
>>>> You can already make contributions to services that would allow
>>>> you to implement this sort of content filtering.
>>>> For instance, you could contribute a RequestFilter. Alternatively,
>>>> you could contribute a Dispatcher to teh MasterDispatcher service.
>>>> Contributions to MasterDispatcher are ordered, so you can
>>>> contribute your "AssetBlockerDispatcher" before the asset service,
>>>> intercept requests to "forbidden" assets,
>>>> and respond appropriately.  You could then make your custom
>>>> dispatcher (or request filter) configurable in the manner that you
>>>> desire.
>>>> You don't rewrite any of the asset service, you get your content
>>>> filtering, and you can write it as a drop-in module for any new
>>>> projects.
>>>>
>>>> Robert
>>>>
>>>> On Jul 26, 2007, at 7/266:18 PM , Daniel Jue wrote:
>>>>
>>>>> Thiago, my apologies.  You are correct.  I would think this is  
>>>>> big a
>>>>> problem if you can't hide important files from users!
>>>>>
>>>>> Dan
>>>>>
>>>>> On 7/26/07, Thiago H de Paula Figueiredo <[hidden email]>  
>>>>> wrote:
>>>>>> On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>>> Hi,  Just don't put configuration resources there.
>>>>>>
>>>>>> I'm not sure you had understood what I've said.
>>>>>>
>>>>>> My hibernate.cfg.xml is in /src/main/resources. So it is  
>>>>>> copied by
>>>>>> Eclipse/NetBeans/Maven/whatever to my webapp's classpath. And
>>>>>> anything in
>>>>>> the classpath, as far as I can see, is accessible via
>>>>>> <applicatiourl>/assets. As many frameworks expect their
>>>>>> configuration
>>>>>> files to be in the classpath, I think we have a little, easy to
>>>>>> solve
>>>>>> problem here. :)
>>>>>>
>>>>>> Thiago
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> --
>>>>>> --
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> --
>>>>> -
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/-T5--Security- 
> of-files-in-the-classpath-tf4153267.html#a11978578
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Thiago H de Paula Figueiredo
On Fri, 03 Aug 2007 05:33:55 -0300, Robert Zeigler <[hidden email]>  
wrote:

> Nope. Zero configuration necessary for the basic functionality.
> Keep in mind, however, that the default configuration is pretty  
> restrictive, since
> it is whitelist-based, and the only entries added by default are the

Would a black list intead of a white list better? I suppose there are less  
files to hide than files to allow access.

Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Francois Armand
Thiago H de Paula Figueiredo wrote:
> Would a black list intead of a white list better? I suppose there are
> less files to hide than files to allow access.
Well, I think that one of the best principle in security is "explicit
authorization" : you just do not want that a confidential file is
accessible by error, because a user forgot to hide it.
But I agree that the white list should authorize jokers to enable
"*.jpg" kind of filter (and if you name your confidential file
"picture_of_my_secret_weapon.jpg", well,  to bad for you ;)

--
Francois Armand
Etudes & Développements J2EE
LINAGORA SA - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org 
FederID - http://www.federid.org/
Open Source identities management and federation


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Thiago H de Paula Figueiredo
On Fri, 03 Aug 2007 10:03:37 -0300, Francois Armand <[hidden email]>  
wrote:

> Thiago H de Paula Figueiredo wrote:
>> Would a black list intead of a white list better? I suppose there are  
>> less files to hide than files to allow access.
> Well, I think that one of the best principle in security is "explicit  
> authorization" : you just do not want that a confidential file is  
> accessible by error, because a user forgot to hide it.

That's a very good point. ;)

> But I agree that the white list should authorize jokers to enable  
> "*.jpg" kind of filter (and if you name your confidential file  
> "picture_of_my_secret_weapon.jpg", well,  to bad for you ;)

Maybe we could allow any .jpg, .gif, .jpg and .css file by default and  
explicitly whitelist the rest.
And no, I don't want to see the picture of your secret weapon, whatever it  
is. :P

Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Security of files in the classpath

Robert Zeigler
I don't plan on changing the default configuration from whitelist to  
blacklist... it's the fallback.
I'm a fan of "deny unless explicitly authorized", as well.  The  
AssetProtectionDispatcher
takes an ordered configuration of AssetPathAuthorizer's, with the  
default whitelist implementation
being the "catch all" final authorizer in what amounts to a chain of  
command. So you can certainly
contribute your own implementations of authorizer on top of the  
default.  Having a pattern matching
whitelist would certainly be useful; I'm in a time crunch at the  
moment (and basically will be until the end of August),
but in the beginning of September, I will rework the default  
WhitelistAuthorizer to accept url patterns.

Robert

On Aug 3, 2007, at 8/38:27 AM , Thiago H de Paula Figueiredo wrote:

> On Fri, 03 Aug 2007 10:03:37 -0300, Francois Armand  
> <[hidden email]> wrote:
>
>> Thiago H de Paula Figueiredo wrote:
>>> Would a black list intead of a white list better? I suppose there  
>>> are less files to hide than files to allow access.
>> Well, I think that one of the best principle in security is  
>> "explicit authorization" : you just do not want that a  
>> confidential file is accessible by error, because a user forgot to  
>> hide it.
>
> That's a very good point. ;)
>
>> But I agree that the white list should authorize jokers to enable  
>> "*.jpg" kind of filter (and if you name your confidential file  
>> "picture_of_my_secret_weapon.jpg", well,  to bad for you ;)
>
> Maybe we could allow any .jpg, .gif, .jpg and .css file by default  
> and explicitly whitelist the rest.
> And no, I don't want to see the picture of your secret weapon,  
> whatever it is. :P
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12