You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by kartweel <rh...@exemail.com.au> on 2009/08/14 04:29:57 UTC
Re: [T5] Security of files in the classpath
Hi Guys, Sorry to pull up an old thread, but there doesn't seem to be a lot
about this topic. Was there ever a nice solution implemented for this? 2
years of tapestry framework development later and I can still download all
my class files. I've restricted assets to "authenticated users" using a
method like below, but I thought by now we wouldn't need to be adding custom
solutions to manage this and it would be part of the core project??
Robert Zeigler wrote:
>
> 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
>> <fa...@linagora.com> 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: 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
>
>
>
--
View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24965558.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Markus Joschko <ma...@gmail.com>.
Thanks. In the meantime I found an old posting which basically
contains the same solution.
I'll add it immediately. However I think that should be adressed by
tapestry in a hotfix released,
as every web developer assumes that the files in WEB-INF are save.
On Sat, Aug 15, 2009 at 1:34 PM, martijn.list<ma...@gmail.com> wrote:
> A follow up:
>
> I forgot to add gif
>
> private static final String[] ASSET_WHITE_LIST = {"jpg", "jpeg", "png",
> "gif", "js", "css", "ico"};
>
> /*
> * All the assets that are allowed to be downloaded using the assets service
> (including files without extension and dirs)
> */
> private static final Set<String> assetsWhitelist =
> Collections.synchronizedSet(
> new HashSet<String>(Arrays.asList(ASSET_WHITE_LIST)));
>
>
> martijn.list wrote:
>>
>> Markus Joschko wrote:
>>>
>>> So the ResourceDigestGenerator obiously doesn't protect the class or
>>> tml files for me here.
>>> I am currently thinking of taking the webapplication down as there is
>>> no way of securing passwords in this set4ting.
>>>
>>> Is there a workaround?
>>>
>>
>> I use a HttpServletRequestFilter to whitelist certain assets. I'm still on
>> 5.0.18 so I do not know whether it works with 5.1:
>>
>> /*
>> * All the assets that are allowed to be downloaded using the assets
>> service (including files without extension and dirs)
>> */
>> private static final HashSet<String> assetsWhitelist = new
>> HashSet<String>(Arrays.asList("jpg", "jpeg", "png", "js", "css", "ico"));
>>
>> public void
>> contributeHttpServletRequestHandler(OrderedConfiguration<HttpServletRequestFilter>
>> configuration,
>> @Inject @Value("${access-denied-page}") final String
>> accessDeniedPage)
>> {
>> /*
>> * Create a filter that will block access to some assets. The asset
>> service allows access to some assets we do
>> * not want to expose. The asset service will show all files in
>> /assets/ directory and allows you (by default)
>> * to download some files which you do not want to expose.
>> */
>> HttpServletRequestFilter filter = new HttpServletRequestFilter()
>> {
>> public boolean service(HttpServletRequest request,
>> HttpServletResponse response, HttpServletRequestHandler handler)
>> throws IOException
>> {
>> String path = request.getServletPath();
>>
>> if (path.startsWith("/assets") && (!assetsWhitelist.contains(
>>
>> StringUtils.lowerCase(FilenameUtils.getExtension(path)))))
>> {
>> response.sendRedirect(request.getContextPath() + "/" +
>> accessDeniedPage);
>>
>> return true;
>> }
>>
>> return handler.service(request, response);
>> }
>> };
>>
>> configuration.add("AssetProtectionFilter", filter , "before:*");
>> }
>>
>> Kind regards,
>>
>> Martijn Brinkers
>>
>
>
> --
> Djigzo open source email encryption
>
> ---------------------------------------------------------------------
> 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
Re: [T5] Security of files in the classpath
Posted by "martijn.list" <ma...@gmail.com>.
A follow up:
I forgot to add gif
private static final String[] ASSET_WHITE_LIST = {"jpg", "jpeg", "png",
"gif", "js", "css", "ico"};
/*
* All the assets that are allowed to be downloaded using the assets
service (including files without extension and dirs)
*/
private static final Set<String> assetsWhitelist =
Collections.synchronizedSet(
new HashSet<String>(Arrays.asList(ASSET_WHITE_LIST)));
martijn.list wrote:
> Markus Joschko wrote:
>> So the ResourceDigestGenerator obiously doesn't protect the class or
>> tml files for me here.
>> I am currently thinking of taking the webapplication down as there is
>> no way of securing passwords in this set4ting.
>>
>> Is there a workaround?
>>
>
> I use a HttpServletRequestFilter to whitelist certain assets. I'm still
> on 5.0.18 so I do not know whether it works with 5.1:
>
> /*
> * All the assets that are allowed to be downloaded using the assets
> service (including files without extension and dirs)
> */
> private static final HashSet<String> assetsWhitelist = new
> HashSet<String>(Arrays.asList("jpg", "jpeg", "png", "js", "css", "ico"));
>
> public void
> contributeHttpServletRequestHandler(OrderedConfiguration<HttpServletRequestFilter>
> configuration,
> @Inject @Value("${access-denied-page}") final String
> accessDeniedPage)
> {
> /*
> * Create a filter that will block access to some assets. The asset
> service allows access to some assets we do
> * not want to expose. The asset service will show all files in
> /assets/ directory and allows you (by default)
> * to download some files which you do not want to expose.
> */
> HttpServletRequestFilter filter = new HttpServletRequestFilter()
> {
> public boolean service(HttpServletRequest request,
> HttpServletResponse response, HttpServletRequestHandler handler)
> throws IOException
> {
> String path = request.getServletPath();
>
> if (path.startsWith("/assets") && (!assetsWhitelist.contains(
>
> StringUtils.lowerCase(FilenameUtils.getExtension(path)))))
> {
> response.sendRedirect(request.getContextPath() + "/" +
> accessDeniedPage);
>
> return true;
> }
>
> return handler.service(request, response);
> }
> };
>
> configuration.add("AssetProtectionFilter", filter , "before:*");
> }
>
> Kind regards,
>
> Martijn Brinkers
>
--
Djigzo open source email encryption
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by "martijn.list" <ma...@gmail.com>.
Markus Joschko wrote:
> So the ResourceDigestGenerator obiously doesn't protect the class or
> tml files for me here.
> I am currently thinking of taking the webapplication down as there is
> no way of securing passwords in this setting.
>
> Is there a workaround?
>
I use a HttpServletRequestFilter to whitelist certain assets. I'm still
on 5.0.18 so I do not know whether it works with 5.1:
/*
* All the assets that are allowed to be downloaded using the assets
service (including files without extension and dirs)
*/
private static final HashSet<String> assetsWhitelist = new
HashSet<String>(Arrays.asList("jpg", "jpeg", "png", "js", "css", "ico"));
public void
contributeHttpServletRequestHandler(OrderedConfiguration<HttpServletRequestFilter>
configuration,
@Inject @Value("${access-denied-page}") final String
accessDeniedPage)
{
/*
* Create a filter that will block access to some assets. The asset
service allows access to some assets we do
* not want to expose. The asset service will show all files in
/assets/ directory and allows you (by default)
* to download some files which you do not want to expose.
*/
HttpServletRequestFilter filter = new HttpServletRequestFilter()
{
public boolean service(HttpServletRequest request,
HttpServletResponse response, HttpServletRequestHandler handler)
throws IOException
{
String path = request.getServletPath();
if (path.startsWith("/assets") && (!assetsWhitelist.contains(
StringUtils.lowerCase(FilenameUtils.getExtension(path)))))
{
response.sendRedirect(request.getContextPath() + "/" +
accessDeniedPage);
return true;
}
return handler.service(request, response);
}
};
configuration.add("AssetProtectionFilter", filter , "before:*");
}
Kind regards,
Martijn Brinkers
--
Djigzo open source email encryption
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Markus Joschko <ma...@gmail.com>.
Ouch. This is a CRITICAL issue. I have a "normal" tapestry application
(5.1.0.5) without additional security checks and
I can download anything from my Web-Inf directory. Property files,
class files, everything. Also the tml files are accessible from the
outside world.
So the ResourceDigestGenerator obiously doesn't protect the class or
tml files for me here.
I am currently thinking of taking the webapplication down as there is
no way of securing passwords in this setting.
Is there a workaround?
Regards,
Markus
On Sat, Aug 15, 2009 at 5:54 AM, kartweel<rh...@exemail.com.au> wrote:
>
> I thought the digest generator is meant to make a different digest for each
> file, but it seems to be for the whole app?, or is that nnnnnnnn bit
> something to do with app versioning for caching and what not and not the
> digest?. This whole thread has some ideas for a white list approach to files
> on the classpath, but I thought by now tapestry would have something out of
> the box rather than a custom solution for it... I'm having a look into the
> resourceDigestGenerator, but at the moment it isn't the highest thing on my
> list.
>
>
> Geoff Callender-2 wrote:
>>
>> Ouch, now I get it. WEB-INF and all its contents are in fact visible,
>> directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard
>> to find out the value of nnnnnnnnnnnnnnnn.
>>
>> Suggestions anyone?
>>
>
> --
> View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24981387.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
Re: [T5] Security of files in the classpath
Posted by "Juan E. Maya" <ma...@gmail.com>.
I've Voted too. Also thanks to "kartweel" for pointing this out. It
seems the is not ResourceDigestGenerator applied to asset resources
:S It's a nasty bug :(
On Sat, Aug 15, 2009 at 2:41 PM, Geoff
Callender<ge...@gmail.com> wrote:
> Thanks, Thiago. I've voted for it. To everyone who is concerned about this,
> please vote too.
>
> On 15/08/2009, at 10:22 PM, Thiago H. de Paula Figueiredo wrote:
>
>> Em Sat, 15 Aug 2009 00:37:45 -0300, Geoff Callender
>> <ge...@gmail.com> escreveu:
>>
>>> Ouch, now I get it. WEB-INF and all its contents are in fact visible,
>>> directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard to
>>> find out the value of nnnnnnnnnnnnnnnn.
>>
>> I couldn't find any JIRA issue about it, so I created one:
>> https://issues.apache.org/jira/browse/TAP5-815.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java consultant, developer, and instructor
>> http://www.arsmachina.com.br/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
Re: [T5] Security of files in the classpath
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 14 Aug 2009 09:28:48 -0300, Geoff Callender
<ge...@gmail.com> escreveu:
> Isn't this simply due to a Maven convention which has passed its "use
> by" date?
I don't think so.
> Why not put .java, .tml, and .properties together in the source tree,
> and compile them all into WEB-INF/classes/ where they're automatically
> hidden from the users?
Maven, when packaging a web app, copies all the files inside
src/main/resources to the classpath root folder (WEB-INF/classes in web
applications).
The issue here is about how Tapestry handles asset classpath requests.
> Surely this makes so much sense. It's what I do with Ant and it seems to
> work a treat. Or have I missed something?
Yes. :) In this case, Ant and Maven are just different tools used to
package webapps.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Geoff Callender <ge...@gmail.com>.
Thanks, Thiago. I've voted for it. To everyone who is concerned about
this, please vote too.
On 15/08/2009, at 10:22 PM, Thiago H. de Paula Figueiredo wrote:
> Em Sat, 15 Aug 2009 00:37:45 -0300, Geoff Callender <geoff.callender.jumpstart@gmail.com
> > escreveu:
>
>> Ouch, now I get it. WEB-INF and all its contents are in fact
>> visible, directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and
>> it's not hard to find out the value of nnnnnnnnnnnnnnnn.
>
> I couldn't find any JIRA issue about it, so I created one: https://issues.apache.org/jira/browse/TAP5-815
> .
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/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
Re: [T5] Security of files in the classpath
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 15 Aug 2009 00:37:45 -0300, Geoff Callender
<ge...@gmail.com> escreveu:
> Ouch, now I get it. WEB-INF and all its contents are in fact visible,
> directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard
> to find out the value of nnnnnnnnnnnnnnnn.
I couldn't find any JIRA issue about it, so I created one:
https://issues.apache.org/jira/browse/TAP5-815.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by kartweel <rh...@exemail.com.au>.
I thought the digest generator is meant to make a different digest for each
file, but it seems to be for the whole app?, or is that nnnnnnnn bit
something to do with app versioning for caching and what not and not the
digest?. This whole thread has some ideas for a white list approach to files
on the classpath, but I thought by now tapestry would have something out of
the box rather than a custom solution for it... I'm having a look into the
resourceDigestGenerator, but at the moment it isn't the highest thing on my
list.
Geoff Callender-2 wrote:
>
> Ouch, now I get it. WEB-INF and all its contents are in fact visible,
> directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard
> to find out the value of nnnnnnnnnnnnnnnn.
>
> Suggestions anyone?
>
--
View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24981387.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Geoff Callender <ge...@gmail.com>.
Ouch, now I get it. WEB-INF and all its contents are in fact visible,
directly below yourapp/assets/ctx/nnnnnnnnnnnnnnnn/, and it's not hard
to find out the value of nnnnnnnnnnnnnnnn.
Suggestions anyone?
On 15/08/2009, at 10:34 AM, kartweel wrote:
>
> http://jumpstart.doublenegative.com.au:8080/jumpstart/assets/ctx/9f6f05886c53821a/WEB-INF/classes/jumpstart/web/services/AppModule.class
>
> you can access the entire web app, it even gives you directory
> listings
>
>
>
> Geoff Callender-2 wrote:
>>
>> Isn't this simply due to a Maven convention which has passed its "use
>> by" date? Why not put .java, .tml, and .properties together in the
>> source tree, and compile them all into WEB-INF/classes/ where they're
>> automatically hidden from the users? Surely this makes so much sense.
>> It's what I do with Ant and it seems to work a treat. Or have I
>> missed
>> something?
>>
>> Eg. correct me if I'm wrong but I'm pretty sure that only the css and
>> images are downloadable from here:
>> http://jumpstart.doublenegative.com.au:8080/jumpstart/
>>
>> Geoff
>>
>> On 14/08/2009, at 7:07 PM, Juan E. Maya wrote:
>>
>>> The ResourceDigestGenerator by default secures files with extension:
>>> .tml and .class. To add more restrictions you'd have to contribute
>>> ResourceDigestGenerator. Something like this:
>>>
>>> public static void
>>> contributeResourceDigestGenerator(Configuration<String>
>>> configuration)
>>> {
>>> configuration.add("properties");
>>> configuration.add("xml");
>>> }
>>>
>>> However i agree that this should be documented or even created by
>>> the
>>> maven archetype. It's something a new user could easily forget with
>>> devastating consequences.
>>>
>>> On Fri, Aug 14, 2009 at 4:29 AM, kartweel<rh...@exemail.com.au>
>>> wrote:
>>>>
>>>> Hi Guys, Sorry to pull up an old thread, but there doesn't seem to
>>>> be a lot
>>>> about this topic. Was there ever a nice solution implemented for
>>>> this? 2
>>>> years of tapestry framework development later and I can still
>>>> download all
>>>> my class files. I've restricted assets to "authenticated users"
>>>> using a
>>>> method like below, but I thought by now we wouldn't need to be
>>>> adding custom
>>>> solutions to manage this and it would be part of the core project??
>>>>
>>>>
>>>> Robert Zeigler wrote:
>>>>>
>>>>> 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
>>>>>> <fa...@linagora.com> 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: 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
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24965558.html
>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24980563.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
Re: [T5] Security of files in the classpath
Posted by kartweel <rh...@exemail.com.au>.
http://jumpstart.doublenegative.com.au:8080/jumpstart/assets/ctx/9f6f05886c53821a/WEB-INF/classes/jumpstart/web/services/AppModule.class
you can access the entire web app, it even gives you directory listings
Geoff Callender-2 wrote:
>
> Isn't this simply due to a Maven convention which has passed its "use
> by" date? Why not put .java, .tml, and .properties together in the
> source tree, and compile them all into WEB-INF/classes/ where they're
> automatically hidden from the users? Surely this makes so much sense.
> It's what I do with Ant and it seems to work a treat. Or have I missed
> something?
>
> Eg. correct me if I'm wrong but I'm pretty sure that only the css and
> images are downloadable from here:
> http://jumpstart.doublenegative.com.au:8080/jumpstart/
>
> Geoff
>
> On 14/08/2009, at 7:07 PM, Juan E. Maya wrote:
>
>> The ResourceDigestGenerator by default secures files with extension:
>> .tml and .class. To add more restrictions you'd have to contribute
>> ResourceDigestGenerator. Something like this:
>>
>> public static void
>> contributeResourceDigestGenerator(Configuration<String> configuration)
>> {
>> configuration.add("properties");
>> configuration.add("xml");
>> }
>>
>> However i agree that this should be documented or even created by the
>> maven archetype. It's something a new user could easily forget with
>> devastating consequences.
>>
>> On Fri, Aug 14, 2009 at 4:29 AM, kartweel<rh...@exemail.com.au> wrote:
>>>
>>> Hi Guys, Sorry to pull up an old thread, but there doesn't seem to
>>> be a lot
>>> about this topic. Was there ever a nice solution implemented for
>>> this? 2
>>> years of tapestry framework development later and I can still
>>> download all
>>> my class files. I've restricted assets to "authenticated users"
>>> using a
>>> method like below, but I thought by now we wouldn't need to be
>>> adding custom
>>> solutions to manage this and it would be part of the core project??
>>>
>>>
>>> Robert Zeigler wrote:
>>>>
>>>> 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
>>>>> <fa...@linagora.com> 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: 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
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24965558.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
--
View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24980563.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Security of files in the classpath
Posted by Geoff Callender <ge...@gmail.com>.
Isn't this simply due to a Maven convention which has passed its "use
by" date? Why not put .java, .tml, and .properties together in the
source tree, and compile them all into WEB-INF/classes/ where they're
automatically hidden from the users? Surely this makes so much sense.
It's what I do with Ant and it seems to work a treat. Or have I missed
something?
Eg. correct me if I'm wrong but I'm pretty sure that only the css and
images are downloadable from here: http://jumpstart.doublenegative.com.au:8080/jumpstart/
Geoff
On 14/08/2009, at 7:07 PM, Juan E. Maya wrote:
> The ResourceDigestGenerator by default secures files with extension:
> .tml and .class. To add more restrictions you'd have to contribute
> ResourceDigestGenerator. Something like this:
>
> public static void
> contributeResourceDigestGenerator(Configuration<String> configuration)
> {
> configuration.add("properties");
> configuration.add("xml");
> }
>
> However i agree that this should be documented or even created by the
> maven archetype. It's something a new user could easily forget with
> devastating consequences.
>
> On Fri, Aug 14, 2009 at 4:29 AM, kartweel<rh...@exemail.com.au> wrote:
>>
>> Hi Guys, Sorry to pull up an old thread, but there doesn't seem to
>> be a lot
>> about this topic. Was there ever a nice solution implemented for
>> this? 2
>> years of tapestry framework development later and I can still
>> download all
>> my class files. I've restricted assets to "authenticated users"
>> using a
>> method like below, but I thought by now we wouldn't need to be
>> adding custom
>> solutions to manage this and it would be part of the core project??
>>
>>
>> Robert Zeigler wrote:
>>>
>>> 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
>>>> <fa...@linagora.com> 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: 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
>>>
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24965558.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [T5] Security of files in the classpath
Posted by "Juan E. Maya" <ma...@gmail.com>.
The ResourceDigestGenerator by default secures files with extension:
.tml and .class. To add more restrictions you'd have to contribute
ResourceDigestGenerator. Something like this:
public static void
contributeResourceDigestGenerator(Configuration<String> configuration)
{
configuration.add("properties");
configuration.add("xml");
}
However i agree that this should be documented or even created by the
maven archetype. It's something a new user could easily forget with
devastating consequences.
On Fri, Aug 14, 2009 at 4:29 AM, kartweel<rh...@exemail.com.au> wrote:
>
> Hi Guys, Sorry to pull up an old thread, but there doesn't seem to be a lot
> about this topic. Was there ever a nice solution implemented for this? 2
> years of tapestry framework development later and I can still download all
> my class files. I've restricted assets to "authenticated users" using a
> method like below, but I thought by now we wouldn't need to be adding custom
> solutions to manage this and it would be part of the core project??
>
>
> Robert Zeigler wrote:
>>
>> 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
>>> <fa...@linagora.com> 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: 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
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/-T5--Security-of-files-in-the-classpath-tp11816097p24965558.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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