Re: [T5] Security of files in the classpath
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, kartweelr...@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 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//, and it's not hard to find out the value of . 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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 HashSetString assetsWhitelist = new
HashSetString(Arrays.asList(jpg, jpeg, png, js, css, ico));
public void
contributeHttpServletRequestHandler(OrderedConfigurationHttpServletRequestFilter
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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 SetString assetsWhitelist =
Collections.synchronizedSet(
new HashSetString(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 HashSetString assetsWhitelist = new
HashSetString(Arrays.asList(jpg, jpeg, png, js, css, ico));
public void
contributeHttpServletRequestHandler(OrderedConfigurationHttpServletRequestFilter
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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.listmartijn.l...@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 SetString assetsWhitelist =
Collections.synchronizedSet(
new HashSetString(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 HashSetString assetsWhitelist = new
HashSetString(Arrays.asList(jpg, jpeg, png, js, css, ico));
public void
contributeHttpServletRequestHandler(OrderedConfigurationHttpServletRequestFilter
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
Em Sat, 15 Aug 2009 00:37:45 -0300, Geoff Callender geoff.callender.jumpst...@gmail.com escreveu: Ouch, now I get it. WEB-INF and all its contents are in fact visible, directly below yourapp/assets/ctx//, and it's not hard to find out the value of . 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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.jumpst...@gmail.com escreveu: Ouch, now I get it. WEB-INF and all its contents are in fact visible, directly below yourapp/assets/ctx//, and it's not hard to find out the value of . 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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 Callendergeoff.callender.jumpst...@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 geoff.callender.jumpst...@gmail.com escreveu: Ouch, now I get it. WEB-INF and all its contents are in fact visible, directly below yourapp/assets/ctx//, and it's not hard to find out the value of . 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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(ConfigurationString 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, kartweelr...@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
farm...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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(ConfigurationString 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, kartweelr...@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
farm...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
Em Fri, 14 Aug 2009 09:28:48 -0300, Geoff Callender geoff.callender.jumpst...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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(ConfigurationString 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, kartweelr...@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
farm...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@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.
Re: [T5] Security of files in the classpath
Ouch, now I get it. WEB-INF and all its contents are in fact visible,
directly below yourapp/assets/ctx//, and it's not hard
to find out the value of .
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(ConfigurationString
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, kartweelr...@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
farm...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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 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//, and it's not hard to find out the value of . 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
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 farm...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5] Security of files in the classpath
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/ ViewComponentsp=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 [EMAIL PROTECTED] wrote: On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
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(
ConfigurationString 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/
ViewComponentsp=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 [EMAIL PROTECTED]
wrote:
On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Re: [T5] Security of files in the classpath
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
On Fri, 03 Aug 2007 05:33:55 -0300, Robert Zeigler [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
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/ ViewComponentsp=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 [EMAIL PROTECTED] wrote: On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
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 [EMAIL PROTECTED] wrote: On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
On Thu, 26 Jul 2007 18:18:42 -0300, Chris Lewis [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
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 [EMAIL PROTECTED] wrote: On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
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 [EMAIL PROTECTED] wrote: On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
On Thu, 26 Jul 2007 16:46:37 -0300, Daniel Jue [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Security of files in the classpath
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
