You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Dmitry Gusev <dm...@gmail.com> on 2009/08/25 14:12:15 UTC
Running Tapestry 5.0.18 on Google App Engine
FYI
Here is the running t5 app: http://ping-service.appspot.com/
It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
Datastore/Mail/Cron/URLFetch/Google Accounts Security
Works pretty well.
I had to implement some hacks to develope with t5 on local dev server (t5
error page refuse to work properly there by default, but works ok in
appengine cloud), here is the solution:
http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by Alex Kotchnev <ak...@gmail.com>.
Dmitry,
extremely cool tip, the hack to get the local dev app server running is
highly appreciated !
Cheers,
Alex K
On Tue, Aug 25, 2009 at 8:12 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> FYI
>
> Here is the running t5 app: http://ping-service.appspot.com/
>
> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>
> Works pretty well.
>
> I had to implement some hacks to develope with t5 on local dev server (t5
> error page refuse to work properly there by default, but works ok in
> appengine cloud), here is the solution:
>
>
> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by Robert Zeigler <ro...@scazdl.org>.
Ah, right... blackbird was introduced in 5.1.
I could probably check for the symbol in the module and provide it if
it doesn't otherwise exist.
Robert
On Aug 27, 2009, at 8/2712:44 AM , Alex Kotchnev wrote:
> @Robert,
> thanks for releasing the 1.0.0 version. I added it, it seems to
> work OK,
> with a minor issue. I'm using 5.0.18, and when I try to access a
> resource
> that shouldn't be accessible, I get the following exception:
>
>
> - org.apache.tapestry5.ioc.internal.OperationExceptionSymbol
> 'tapestry.blackbird.path' is not defined.
> trace
> - Realizing service RegexAuthorizer
> - Invoking
>
> com.saiwaisolutions.tapestry.services.RegexAuthorizer(Collection) (at
> RegexAuthorizer.java:29) via
>
> com
> .saiwaisolutions
> .tapestry.services.AssetProtectionModule.bind(ServiceBinder)
> (at AssetProtectionModule.java:19)
> - Collecting unordered configuration for service RegexAuthorizer
> - Invoking method
>
> com
> .saiwaisolutions
> .tapestry
> .services
> .AssetProtectionModule.contributeRegexAuthorizer(Configuration,
> String, String, String) (at AssetProtectionModule.java:49).
> - Determining injection value for parameter #3 (java.lang.String)
> -
>
>
> It seems like 5.1 defines this symbol out of the box, while 5.0.18
> doesn't. Adding the symbol addresses the issue
>
>
> NICE WORK !
>
> Cheers,
>
> Alex K
>
>
> On Wed, Aug 26, 2009 at 1:55 PM, Robert Zeigler <ro...@scazdl.org>
> wrote:
>
>> Try version 1.0.0, just released today. ;)
>> See my comment on issue 815 for the maven url, artifact id, etc.
>>
>> In any event, there's a framework solution in place already... it's
>> just
>> that it's a blacklist-based solution instead of a whitelist-based
>> solution.
>> Although whitelist-based security tends to be more secure,
>> blacklisting has
>> its merits. For a webapp, for example, there's often a lot more
>> that you
>> want accessible than otherwise (all of
>> your .png, .jpg, .jpeg, .gif, .js,
>> .css files, for example). The solution I wrote allows for pattern-
>> based
>> whitelisting, but that can be dangerous: it's awfully easy to write a
>> pattern that isn't as secure as you think it is. Anyway, just food
>> for
>> thought... you can contribute to the framework as is and have it
>> immediately
>> block access to dangerous resources for you. In fact, you could
>> write a
>> standalone module that does nothing other than contribute your
>> blacklist
>> preferences (eg: *.xml, *.class, etc.), then just add that module
>> as a
>> dependency for any new project. *shrug*
>>
>> Robert
>>
>>
>> On Aug 26, 2009, at 8/261:21 AM , Alex Kotchnev wrote:
>>
>> Christian,
>>> you seem to indicate that there's an easy fix for this on the
>>> mailing
>>> list; however, the last discussion there is from around 2007; the
>>> module
>>> that Robert is referring to is out of date (e.g. referring to old
>>> package
>>> names, etc). Any other tips on addressing this ?
>>>
>>> I'm completely taken aback by such a gaping security hole in the
>>> framework. Considering that this issue has been known since 2007,
>>> I'm
>>> completely blown away that the framework doesn't provide a
>>> solution in T5
>>> (not in T5.1).
>>>
>>> Cheers,
>>>
>>> Alex K
>>>
>>> On Tue, Aug 25, 2009 at 8:44 AM, Christian Riedel
>>> <ch...@gmx.net>wrote:
>>>
>>> FYI you should (all) be aware of TAP-815*! Your assets** are
>>> readable for
>>>> everybody!
>>>> It is certainly not as critical as in some pages named in this
>>>> thread***
>>>> but in general it could cause some bad reputation for T5.
>>>>
>>>> Apart from that I just can say: nice work! ;)
>>>>
>>>>
>>>> *jira ticket:
>>>> https://issues.apache.org/jira/browse/TAP5-815
>>>>
>>>> **example asset
>>>> http://ping-service.appspot.com/assets/META-INF/persistence.xml
>>>>
>>>> ***
>>>>
>>>>
>>>> http://www.nabble.com/-REQUEST--Live-T5-web-sites%2C-quotes%2C-marketting-ts23050433s302.html#a23054798
>>>>
>>>> easy workaround:
>>>>
>>>>
>>>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-ts11816097s302.html#a11816097
>>>>
>>>>
>>>> regards
>>>> christian
>>>>
>>>>
>>>> Dmitry Gusev schrieb:
>>>>
>>>> FYI
>>>>
>>>>>
>>>>> Here is the running t5 app: http://ping-service.appspot.com/
>>>>>
>>>>> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
>>>>> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>>>>>
>>>>> Works pretty well.
>>>>>
>>>>> I had to implement some hacks to develope with t5 on local dev
>>>>> server
>>>>> (t5
>>>>> error page refuse to work properly there by default, but works
>>>>> ok in
>>>>> appengine cloud), here is the solution:
>>>>>
>>>>>
>>>>>
>>>>> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: Running Tapestry 5.0.18 on Google App Engine
Posted by Alex Kotchnev <ak...@gmail.com>.
@Robert,
thanks for releasing the 1.0.0 version. I added it, it seems to work OK,
with a minor issue. I'm using 5.0.18, and when I try to access a resource
that shouldn't be accessible, I get the following exception:
- org.apache.tapestry5.ioc.internal.OperationExceptionSymbol
'tapestry.blackbird.path' is not defined.
trace
- Realizing service RegexAuthorizer
- Invoking
com.saiwaisolutions.tapestry.services.RegexAuthorizer(Collection) (at
RegexAuthorizer.java:29) via
com.saiwaisolutions.tapestry.services.AssetProtectionModule.bind(ServiceBinder)
(at AssetProtectionModule.java:19)
- Collecting unordered configuration for service RegexAuthorizer
- Invoking method
com.saiwaisolutions.tapestry.services.AssetProtectionModule.contributeRegexAuthorizer(Configuration,
String, String, String) (at AssetProtectionModule.java:49).
- Determining injection value for parameter #3 (java.lang.String)
-
It seems like 5.1 defines this symbol out of the box, while 5.0.18
doesn't. Adding the symbol addresses the issue
NICE WORK !
Cheers,
Alex K
On Wed, Aug 26, 2009 at 1:55 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> Try version 1.0.0, just released today. ;)
> See my comment on issue 815 for the maven url, artifact id, etc.
>
> In any event, there's a framework solution in place already... it's just
> that it's a blacklist-based solution instead of a whitelist-based solution.
> Although whitelist-based security tends to be more secure, blacklisting has
> its merits. For a webapp, for example, there's often a lot more that you
> want accessible than otherwise (all of your .png, .jpg, .jpeg, .gif, .js,
> .css files, for example). The solution I wrote allows for pattern-based
> whitelisting, but that can be dangerous: it's awfully easy to write a
> pattern that isn't as secure as you think it is. Anyway, just food for
> thought... you can contribute to the framework as is and have it immediately
> block access to dangerous resources for you. In fact, you could write a
> standalone module that does nothing other than contribute your blacklist
> preferences (eg: *.xml, *.class, etc.), then just add that module as a
> dependency for any new project. *shrug*
>
> Robert
>
>
> On Aug 26, 2009, at 8/261:21 AM , Alex Kotchnev wrote:
>
> Christian,
>> you seem to indicate that there's an easy fix for this on the mailing
>> list; however, the last discussion there is from around 2007; the module
>> that Robert is referring to is out of date (e.g. referring to old package
>> names, etc). Any other tips on addressing this ?
>>
>> I'm completely taken aback by such a gaping security hole in the
>> framework. Considering that this issue has been known since 2007, I'm
>> completely blown away that the framework doesn't provide a solution in T5
>> (not in T5.1).
>>
>> Cheers,
>>
>> Alex K
>>
>> On Tue, Aug 25, 2009 at 8:44 AM, Christian Riedel
>> <ch...@gmx.net>wrote:
>>
>> FYI you should (all) be aware of TAP-815*! Your assets** are readable for
>>> everybody!
>>> It is certainly not as critical as in some pages named in this thread***
>>> but in general it could cause some bad reputation for T5.
>>>
>>> Apart from that I just can say: nice work! ;)
>>>
>>>
>>> *jira ticket:
>>> https://issues.apache.org/jira/browse/TAP5-815
>>>
>>> **example asset
>>> http://ping-service.appspot.com/assets/META-INF/persistence.xml
>>>
>>> ***
>>>
>>>
>>> http://www.nabble.com/-REQUEST--Live-T5-web-sites%2C-quotes%2C-marketting-ts23050433s302.html#a23054798
>>>
>>> easy workaround:
>>>
>>>
>>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-ts11816097s302.html#a11816097
>>>
>>>
>>> regards
>>> christian
>>>
>>>
>>> Dmitry Gusev schrieb:
>>>
>>> FYI
>>>
>>>>
>>>> Here is the running t5 app: http://ping-service.appspot.com/
>>>>
>>>> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
>>>> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>>>>
>>>> Works pretty well.
>>>>
>>>> I had to implement some hacks to develope with t5 on local dev server
>>>> (t5
>>>> error page refuse to work properly there by default, but works ok in
>>>> appengine cloud), here is the solution:
>>>>
>>>>
>>>>
>>>> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> 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: Running Tapestry 5.0.18 on Google App Engine
Posted by Ulrich Stärk <ul...@spielviel.de>.
You'd still have to write them. The framework default is to allow access to sensitive files. That's
the problem here.
On 26.08.2009 20:43 schrieb Thiago H. de Paula Figueiredo:
> Em Wed, 26 Aug 2009 15:09:08 -0300, Ulrich Stärk <ul...@spielviel.de>
> escreveu:
>
>> There is no framework solution for context assets.
>> ResourceDigestGenerator is purely for classpath assets.
>
> There are two: a RequestFilter or a Dispatcher.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 26 Aug 2009 15:09:08 -0300, Ulrich Stärk <ul...@spielviel.de>
escreveu:
> There is no framework solution for context assets.
> ResourceDigestGenerator is purely for classpath assets.
There are two: a RequestFilter or a Dispatcher.
--
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: Running Tapestry 5.0.18 on Google App Engine
Posted by Ulrich Stärk <ul...@spielviel.de>.
There is no framework solution for context assets. ResourceDigestGenerator is purely for classpath
assets.
Uli
On 26.08.2009 19:55 schrieb Robert Zeigler:
> Try version 1.0.0, just released today. ;)
> See my comment on issue 815 for the maven url, artifact id, etc.
>
> In any event, there's a framework solution in place already... it's just
> that it's a blacklist-based solution instead of a whitelist-based
> solution. Although whitelist-based security tends to be more secure,
> blacklisting has its merits. For a webapp, for example, there's often a
> lot more that you want accessible than otherwise (all of your .png,
> .jpg, .jpeg, .gif, .js, .css files, for example). The solution I wrote
> allows for pattern-based whitelisting, but that can be dangerous: it's
> awfully easy to write a pattern that isn't as secure as you think it
> is. Anyway, just food for thought... you can contribute to the
> framework as is and have it immediately block access to dangerous
> resources for you. In fact, you could write a standalone module that
> does nothing other than contribute your blacklist preferences (eg:
> *.xml, *.class, etc.), then just add that module as a dependency for any
> new project. *shrug*
>
> Robert
>
> On Aug 26, 2009, at 8/261:21 AM , Alex Kotchnev wrote:
>
>> Christian,
>> you seem to indicate that there's an easy fix for this on the mailing
>> list; however, the last discussion there is from around 2007; the module
>> that Robert is referring to is out of date (e.g. referring to old package
>> names, etc). Any other tips on addressing this ?
>>
>> I'm completely taken aback by such a gaping security hole in the
>> framework. Considering that this issue has been known since 2007, I'm
>> completely blown away that the framework doesn't provide a solution in T5
>> (not in T5.1).
>>
>> Cheers,
>>
>> Alex K
>>
>> On Tue, Aug 25, 2009 at 8:44 AM, Christian Riedel
>> <ch...@gmx.net>wrote:
>>
>>> FYI you should (all) be aware of TAP-815*! Your assets** are readable
>>> for
>>> everybody!
>>> It is certainly not as critical as in some pages named in this thread***
>>> but in general it could cause some bad reputation for T5.
>>>
>>> Apart from that I just can say: nice work! ;)
>>>
>>>
>>> *jira ticket:
>>> https://issues.apache.org/jira/browse/TAP5-815
>>>
>>> **example asset
>>> http://ping-service.appspot.com/assets/META-INF/persistence.xml
>>>
>>> ***
>>>
>>> http://www.nabble.com/-REQUEST--Live-T5-web-sites%2C-quotes%2C-marketting-ts23050433s302.html#a23054798
>>>
>>>
>>> easy workaround:
>>>
>>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-ts11816097s302.html#a11816097
>>>
>>>
>>>
>>> regards
>>> christian
>>>
>>>
>>> Dmitry Gusev schrieb:
>>>
>>> FYI
>>>>
>>>> Here is the running t5 app: http://ping-service.appspot.com/
>>>>
>>>> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
>>>> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>>>>
>>>> Works pretty well.
>>>>
>>>> I had to implement some hacks to develope with t5 on local dev
>>>> server (t5
>>>> error page refuse to work properly there by default, but works ok in
>>>> appengine cloud), here is the solution:
>>>>
>>>>
>>>> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Running Tapestry 5.0.18 on Google App Engine
Posted by Robert Zeigler <ro...@scazdl.org>.
I rescind this comment; just duplicated it. ;)
Robert
On Aug 26, 2009, at 8/262:08 PM , Robert Zeigler wrote:
> Agreed that it's tedious but better to whitelist (cf my e-mail from
> 2007 where I expressed my personal preference for whitelisting).
> I've been playing around with this a bit... have you demonstrated
> the vulnerability in WEB-INF and, eg, template files? I just tried,
> but couldn't duplicate... an example would be helpful...
>
> Robert
>
> On Aug 26, 2009, at 8/261:59 PM , Ulrich Stärk wrote:
>
>> Robert,
>>
>> While whitelisting a lot of extensions might seem tedious, it's a
>> lot less painful than to forget to blacklist the one file that
>> someone might use to compromise the security of your whole web app.
>>
>> The problem we have is that all Tapestry applications are insecure
>> *by default* at the moment. Contributing to the
>> ResourceDigestGenerator only helps with assets on the classpath.
>> Everything in the webapp context, including stuff below WEB-INF and
>> page templates (by the way rendering the check for Tapestry
>> templates inside the StaticFiles RequestFilter useless), is still
>> freely accessible. The lack of a directory listing in newer
>> Tapestry versions only helps a little.
>>
>> Uli
>>
>> On 26.08.2009 19:55 schrieb Robert Zeigler:
>>> Try version 1.0.0, just released today. ;)
>>> See my comment on issue 815 for the maven url, artifact id, etc.
>>> In any event, there's a framework solution in place already...
>>> it's just that it's a blacklist-based solution instead of a
>>> whitelist-based solution. Although whitelist-based security tends
>>> to be more secure, blacklisting has its merits. For a webapp, for
>>> example, there's often a lot more that you want accessible than
>>> otherwise (all of your .png, .jpg, .jpeg, .gif, .js, .css files,
>>> for example). The solution I wrote allows for pattern-based
>>> whitelisting, but that can be dangerous: it's awfully easy to
>>> write a pattern that isn't as secure as you think it is. Anyway,
>>> just food for thought... you can contribute to the framework as is
>>> and have it immediately block access to dangerous resources for
>>> you. In fact, you could write a standalone module that does
>>> nothing other than contribute your blacklist preferences (eg:
>>> *.xml, *.class, etc.), then just add that module as a dependency
>>> for any new project. *shrug*
>>> Robert
>>> On Aug 26, 2009, at 8/261:21 AM , Alex Kotchnev wrote:
>>>> Christian,
>>>> you seem to indicate that there's an easy fix for this on the
>>>> mailing
>>>> list; however, the last discussion there is from around 2007; the
>>>> module
>>>> that Robert is referring to is out of date (e.g. referring to old
>>>> package
>>>> names, etc). Any other tips on addressing this ?
>>>>
>>>> I'm completely taken aback by such a gaping security hole in the
>>>> framework. Considering that this issue has been known since 2007,
>>>> I'm
>>>> completely blown away that the framework doesn't provide a
>>>> solution in T5
>>>> (not in T5.1).
>>>>
>>>> Cheers,
>>>>
>>>> Alex K
>>>>
>>>> On Tue, Aug 25, 2009 at 8:44 AM, Christian Riedel
>>>> <ch...@gmx.net>wrote:
>>>>
>>>>> FYI you should (all) be aware of TAP-815*! Your assets** are
>>>>> readable for
>>>>> everybody!
>>>>> It is certainly not as critical as in some pages named in this
>>>>> thread***
>>>>> but in general it could cause some bad reputation for T5.
>>>>>
>>>>> Apart from that I just can say: nice work! ;)
>>>>>
>>>>>
>>>>> *jira ticket:
>>>>> https://issues.apache.org/jira/browse/TAP5-815
>>>>>
>>>>> **example asset
>>>>> http://ping-service.appspot.com/assets/META-INF/persistence.xml
>>>>>
>>>>> ***
>>>>>
>>>>> http://www.nabble.com/-REQUEST--Live-T5-web-sites%2C-quotes%2C-marketting-ts23050433s302.html#a23054798
>>>>>
>>>>> easy workaround:
>>>>>
>>>>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-ts11816097s302.html#a11816097
>>>>>
>>>>>
>>>>> regards
>>>>> christian
>>>>>
>>>>>
>>>>> Dmitry Gusev schrieb:
>>>>>
>>>>> FYI
>>>>>>
>>>>>> Here is the running t5 app: http://ping-service.appspot.com/
>>>>>>
>>>>>> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
>>>>>> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>>>>>>
>>>>>> Works pretty well.
>>>>>>
>>>>>> I had to implement some hacks to develope with t5 on local dev
>>>>>> server (t5
>>>>>> error page refuse to work properly there by default, but works
>>>>>> ok in
>>>>>> appengine cloud), here is the solution:
>>>>>>
>>>>>>
>>>>>> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by Robert Zeigler <ro...@scazdl.org>.
Agreed that it's tedious but better to whitelist (cf my e-mail from
2007 where I expressed my personal preference for whitelisting).
I've been playing around with this a bit... have you demonstrated the
vulnerability in WEB-INF and, eg, template files? I just tried, but
couldn't duplicate... an example would be helpful...
Robert
On Aug 26, 2009, at 8/261:59 PM , Ulrich Stärk wrote:
> Robert,
>
> While whitelisting a lot of extensions might seem tedious, it's a
> lot less painful than to forget to blacklist the one file that
> someone might use to compromise the security of your whole web app.
>
> The problem we have is that all Tapestry applications are insecure
> *by default* at the moment. Contributing to the
> ResourceDigestGenerator only helps with assets on the classpath.
> Everything in the webapp context, including stuff below WEB-INF and
> page templates (by the way rendering the check for Tapestry
> templates inside the StaticFiles RequestFilter useless), is still
> freely accessible. The lack of a directory listing in newer Tapestry
> versions only helps a little.
>
> Uli
>
> On 26.08.2009 19:55 schrieb Robert Zeigler:
>> Try version 1.0.0, just released today. ;)
>> See my comment on issue 815 for the maven url, artifact id, etc.
>> In any event, there's a framework solution in place already... it's
>> just that it's a blacklist-based solution instead of a whitelist-
>> based solution. Although whitelist-based security tends to be more
>> secure, blacklisting has its merits. For a webapp, for example,
>> there's often a lot more that you want accessible than otherwise
>> (all of your .png, .jpg, .jpeg, .gif, .js, .css files, for
>> example). The solution I wrote allows for pattern-based
>> whitelisting, but that can be dangerous: it's awfully easy to write
>> a pattern that isn't as secure as you think it is. Anyway, just
>> food for thought... you can contribute to the framework as is and
>> have it immediately block access to dangerous resources for you.
>> In fact, you could write a standalone module that does nothing
>> other than contribute your blacklist preferences (eg: *.xml,
>> *.class, etc.), then just add that module as a dependency for any
>> new project. *shrug*
>> Robert
>> On Aug 26, 2009, at 8/261:21 AM , Alex Kotchnev wrote:
>>> Christian,
>>> you seem to indicate that there's an easy fix for this on the
>>> mailing
>>> list; however, the last discussion there is from around 2007; the
>>> module
>>> that Robert is referring to is out of date (e.g. referring to old
>>> package
>>> names, etc). Any other tips on addressing this ?
>>>
>>> I'm completely taken aback by such a gaping security hole in the
>>> framework. Considering that this issue has been known since 2007,
>>> I'm
>>> completely blown away that the framework doesn't provide a
>>> solution in T5
>>> (not in T5.1).
>>>
>>> Cheers,
>>>
>>> Alex K
>>>
>>> On Tue, Aug 25, 2009 at 8:44 AM, Christian Riedel
>>> <ch...@gmx.net>wrote:
>>>
>>>> FYI you should (all) be aware of TAP-815*! Your assets** are
>>>> readable for
>>>> everybody!
>>>> It is certainly not as critical as in some pages named in this
>>>> thread***
>>>> but in general it could cause some bad reputation for T5.
>>>>
>>>> Apart from that I just can say: nice work! ;)
>>>>
>>>>
>>>> *jira ticket:
>>>> https://issues.apache.org/jira/browse/TAP5-815
>>>>
>>>> **example asset
>>>> http://ping-service.appspot.com/assets/META-INF/persistence.xml
>>>>
>>>> ***
>>>>
>>>> http://www.nabble.com/-REQUEST--Live-T5-web-sites%2C-quotes%2C-marketting-ts23050433s302.html#a23054798
>>>>
>>>> easy workaround:
>>>>
>>>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-ts11816097s302.html#a11816097
>>>>
>>>>
>>>> regards
>>>> christian
>>>>
>>>>
>>>> Dmitry Gusev schrieb:
>>>>
>>>> FYI
>>>>>
>>>>> Here is the running t5 app: http://ping-service.appspot.com/
>>>>>
>>>>> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
>>>>> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>>>>>
>>>>> Works pretty well.
>>>>>
>>>>> I had to implement some hacks to develope with t5 on local dev
>>>>> server (t5
>>>>> error page refuse to work properly there by default, but works
>>>>> ok in
>>>>> appengine cloud), here is the solution:
>>>>>
>>>>>
>>>>> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by Ulrich Stärk <ul...@spielviel.de>.
Robert,
While whitelisting a lot of extensions might seem tedious, it's a lot less painful than to forget to
blacklist the one file that someone might use to compromise the security of your whole web app.
The problem we have is that all Tapestry applications are insecure *by default* at the moment.
Contributing to the ResourceDigestGenerator only helps with assets on the classpath. Everything in
the webapp context, including stuff below WEB-INF and page templates (by the way rendering the check
for Tapestry templates inside the StaticFiles RequestFilter useless), is still freely accessible.
The lack of a directory listing in newer Tapestry versions only helps a little.
Uli
On 26.08.2009 19:55 schrieb Robert Zeigler:
> Try version 1.0.0, just released today. ;)
> See my comment on issue 815 for the maven url, artifact id, etc.
>
> In any event, there's a framework solution in place already... it's just
> that it's a blacklist-based solution instead of a whitelist-based
> solution. Although whitelist-based security tends to be more secure,
> blacklisting has its merits. For a webapp, for example, there's often a
> lot more that you want accessible than otherwise (all of your .png,
> .jpg, .jpeg, .gif, .js, .css files, for example). The solution I wrote
> allows for pattern-based whitelisting, but that can be dangerous: it's
> awfully easy to write a pattern that isn't as secure as you think it
> is. Anyway, just food for thought... you can contribute to the
> framework as is and have it immediately block access to dangerous
> resources for you. In fact, you could write a standalone module that
> does nothing other than contribute your blacklist preferences (eg:
> *.xml, *.class, etc.), then just add that module as a dependency for any
> new project. *shrug*
>
> Robert
>
> On Aug 26, 2009, at 8/261:21 AM , Alex Kotchnev wrote:
>
>> Christian,
>> you seem to indicate that there's an easy fix for this on the mailing
>> list; however, the last discussion there is from around 2007; the module
>> that Robert is referring to is out of date (e.g. referring to old package
>> names, etc). Any other tips on addressing this ?
>>
>> I'm completely taken aback by such a gaping security hole in the
>> framework. Considering that this issue has been known since 2007, I'm
>> completely blown away that the framework doesn't provide a solution in T5
>> (not in T5.1).
>>
>> Cheers,
>>
>> Alex K
>>
>> On Tue, Aug 25, 2009 at 8:44 AM, Christian Riedel
>> <ch...@gmx.net>wrote:
>>
>>> FYI you should (all) be aware of TAP-815*! Your assets** are readable
>>> for
>>> everybody!
>>> It is certainly not as critical as in some pages named in this thread***
>>> but in general it could cause some bad reputation for T5.
>>>
>>> Apart from that I just can say: nice work! ;)
>>>
>>>
>>> *jira ticket:
>>> https://issues.apache.org/jira/browse/TAP5-815
>>>
>>> **example asset
>>> http://ping-service.appspot.com/assets/META-INF/persistence.xml
>>>
>>> ***
>>>
>>> http://www.nabble.com/-REQUEST--Live-T5-web-sites%2C-quotes%2C-marketting-ts23050433s302.html#a23054798
>>>
>>>
>>> easy workaround:
>>>
>>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-ts11816097s302.html#a11816097
>>>
>>>
>>>
>>> regards
>>> christian
>>>
>>>
>>> Dmitry Gusev schrieb:
>>>
>>> FYI
>>>>
>>>> Here is the running t5 app: http://ping-service.appspot.com/
>>>>
>>>> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
>>>> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>>>>
>>>> Works pretty well.
>>>>
>>>> I had to implement some hacks to develope with t5 on local dev
>>>> server (t5
>>>> error page refuse to work properly there by default, but works ok in
>>>> appengine cloud), here is the solution:
>>>>
>>>>
>>>> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Running Tapestry 5.0.18 on Google App Engine
Posted by Robert Zeigler <ro...@scazdl.org>.
Try version 1.0.0, just released today. ;)
See my comment on issue 815 for the maven url, artifact id, etc.
In any event, there's a framework solution in place already... it's
just that it's a blacklist-based solution instead of a whitelist-based
solution. Although whitelist-based security tends to be more secure,
blacklisting has its merits. For a webapp, for example, there's often
a lot more that you want accessible than otherwise (all of
your .png, .jpg, .jpeg, .gif, .js, .css files, for example). The
solution I wrote allows for pattern-based whitelisting, but that can
be dangerous: it's awfully easy to write a pattern that isn't as
secure as you think it is. Anyway, just food for thought... you can
contribute to the framework as is and have it immediately block access
to dangerous resources for you. In fact, you could write a standalone
module that does nothing other than contribute your blacklist
preferences (eg: *.xml, *.class, etc.), then just add that module as a
dependency for any new project. *shrug*
Robert
On Aug 26, 2009, at 8/261:21 AM , Alex Kotchnev wrote:
> Christian,
> you seem to indicate that there's an easy fix for this on the
> mailing
> list; however, the last discussion there is from around 2007; the
> module
> that Robert is referring to is out of date (e.g. referring to old
> package
> names, etc). Any other tips on addressing this ?
>
> I'm completely taken aback by such a gaping security hole in the
> framework. Considering that this issue has been known since 2007, I'm
> completely blown away that the framework doesn't provide a solution
> in T5
> (not in T5.1).
>
> Cheers,
>
> Alex K
>
> On Tue, Aug 25, 2009 at 8:44 AM, Christian Riedel
> <ch...@gmx.net>wrote:
>
>> FYI you should (all) be aware of TAP-815*! Your assets** are
>> readable for
>> everybody!
>> It is certainly not as critical as in some pages named in this
>> thread***
>> but in general it could cause some bad reputation for T5.
>>
>> Apart from that I just can say: nice work! ;)
>>
>>
>> *jira ticket:
>> https://issues.apache.org/jira/browse/TAP5-815
>>
>> **example asset
>> http://ping-service.appspot.com/assets/META-INF/persistence.xml
>>
>> ***
>>
>> http://www.nabble.com/-REQUEST--Live-T5-web-sites%2C-quotes%2C-marketting-ts23050433s302.html#a23054798
>>
>> easy workaround:
>>
>> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-ts11816097s302.html#a11816097
>>
>>
>> regards
>> christian
>>
>>
>> Dmitry Gusev schrieb:
>>
>> FYI
>>>
>>> Here is the running t5 app: http://ping-service.appspot.com/
>>>
>>> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
>>> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>>>
>>> Works pretty well.
>>>
>>> I had to implement some hacks to develope with t5 on local dev
>>> server (t5
>>> error page refuse to work properly there by default, but works ok in
>>> appengine cloud), here is the solution:
>>>
>>>
>>> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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: Running Tapestry 5.0.18 on Google App Engine
Posted by Christian Riedel <ch...@gmx.net>.
Yes, Alex, the thread is from 2007, but the workaround that Martijn also
lists here has been posted to the thread just 2 weeks ago.
I use it in my current T5.1 application and it works fine!
martijn.list schrieb:
> Alex Kotchnev wrote:
>> Christian,
>> you seem to indicate that there's an easy fix for this on the mailing
>> list; however, the last discussion there is from around 2007; the module
>> that Robert is referring to is out of date (e.g. referring to old
>> package
>> names, etc). Any other tips on addressing this ?
>>
>> I'm completely taken aback by such a gaping security hole in the
>> framework. Considering that this issue has been known since 2007, I'm
>> completely blown away that the framework doesn't provide a solution
>> in T5
>> (not in T5.1).
>>
>
> I use the following code to whitelist some assets. Access to non white
> listed assets is denied. I have only tested it with T 5.0.18
>
> Martijn Brinkers
>
>
> 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)));
>
> 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)))))
> {
> logger.warn("access to asset " + path + " denied");
>
> response.sendRedirect(request.getContextPath() + "/" +
> accessDeniedPage);
>
> return true;
> }
>
> return handler.service(request, response);
> }
> };
>
> configuration.add("AssetProtectionFilter", filter , "before:*");
> }
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by "martijn.list" <ma...@gmail.com>.
Alex Kotchnev wrote:
> Christian,
> you seem to indicate that there's an easy fix for this on the mailing
> list; however, the last discussion there is from around 2007; the module
> that Robert is referring to is out of date (e.g. referring to old package
> names, etc). Any other tips on addressing this ?
>
> I'm completely taken aback by such a gaping security hole in the
> framework. Considering that this issue has been known since 2007, I'm
> completely blown away that the framework doesn't provide a solution in T5
> (not in T5.1).
>
I use the following code to whitelist some assets. Access to non white
listed assets is denied. I have only tested it with T 5.0.18
Martijn Brinkers
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)));
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)))))
{
logger.warn("access to asset " + path + " denied");
response.sendRedirect(request.getContextPath() + "/" +
accessDeniedPage);
return true;
}
return handler.service(request, response);
}
};
configuration.add("AssetProtectionFilter", filter , "before:*");
}
--
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: Running Tapestry 5.0.18 on Google App Engine
Posted by Alex Kotchnev <ak...@gmail.com>.
Christian,
you seem to indicate that there's an easy fix for this on the mailing
list; however, the last discussion there is from around 2007; the module
that Robert is referring to is out of date (e.g. referring to old package
names, etc). Any other tips on addressing this ?
I'm completely taken aback by such a gaping security hole in the
framework. Considering that this issue has been known since 2007, I'm
completely blown away that the framework doesn't provide a solution in T5
(not in T5.1).
Cheers,
Alex K
On Tue, Aug 25, 2009 at 8:44 AM, Christian Riedel
<ch...@gmx.net>wrote:
> FYI you should (all) be aware of TAP-815*! Your assets** are readable for
> everybody!
> It is certainly not as critical as in some pages named in this thread***
> but in general it could cause some bad reputation for T5.
>
> Apart from that I just can say: nice work! ;)
>
>
> *jira ticket:
> https://issues.apache.org/jira/browse/TAP5-815
>
> **example asset
> http://ping-service.appspot.com/assets/META-INF/persistence.xml
>
> ***
>
> http://www.nabble.com/-REQUEST--Live-T5-web-sites%2C-quotes%2C-marketting-ts23050433s302.html#a23054798
>
> easy workaround:
>
> http://www.nabble.com/-T5--Security-of-files-in-the-classpath-ts11816097s302.html#a11816097
>
>
> regards
> christian
>
>
> Dmitry Gusev schrieb:
>
> FYI
>>
>> Here is the running t5 app: http://ping-service.appspot.com/
>>
>> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
>> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>>
>> Works pretty well.
>>
>> I had to implement some hacks to develope with t5 on local dev server (t5
>> error page refuse to work properly there by default, but works ok in
>> appengine cloud), here is the solution:
>>
>>
>> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by Christian Riedel <ch...@gmx.net>.
Apparently it is also affecting 5.0.18, since you can browse Dimitry's
assets and read the persistence.xml for example.
Thiago H. de Paula Figueiredo schrieb:
> Em Tue, 25 Aug 2009 09:44:35 -0300, Christian Riedel
> <ch...@gmx.net> escreveu:
>
>> FYI you should (all) be aware of TAP-815*! Your assets** are readable
>> for everybody!
>
> AFAIK, this issue doesn't affect T5.0.18, as it happens only with
> versioned assets, something that was introduced in T5.1.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by Onno Scheffers <on...@piraya.nl>.
Hi Dmitry,
thanks for this information. 20 seconds to first page is indeed pretty long,
but if you use a cron-job to keep the application warm, the long startup
time is less of an issue. This was one of my major doubts about Tapestry on
GAE, but your approach seems like a very good work-around.
regards,
Onno
On Wed, Aug 26, 2009 at 11:02 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> It tooks 15 seconds to startup the instance + 5 seconds to render the first
> page (same on my development laptop and GAE cloud)
>
> Thats pretty long but I guess the bottleneck here is not in tapestry but
> rather in spring.
>
> As for cleaning up an instance after it's not being used - I can't tell
> you,
> thats not my case. I've set up cron triggers for executing ping jobs and
> those triggers actually invoke HTTP GET on my tapestry pages, so the app is
> always warm.
>
> On Wed, Aug 26, 2009 at 11:12, Onno Scheffers <on...@piraya.nl> wrote:
>
> >
> > @Dmitry
> > Sorry for hijacking your thread like this. Tapestry on GAE looks very
> > interesting to me.
> > I was wondering how long it takes for the first page to render after the
> > application has just been deployed/suspended. If I'm not mistaken, GAE
> will
> > have cleaned up your instance if it isn't being used much and will have
> to
> > restart the application.
> > Applications made up of servlets and JSPs will be running very quickly,
> but
> > I guess a framework like Tapestry that has to initialize a lot of
> services
> > might take a bit longer?
> >
> >
> > regards,
> >
> > Onno
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by Dmitry Gusev <dm...@gmail.com>.
It tooks 15 seconds to startup the instance + 5 seconds to render the first
page (same on my development laptop and GAE cloud)
Thats pretty long but I guess the bottleneck here is not in tapestry but
rather in spring.
As for cleaning up an instance after it's not being used - I can't tell you,
thats not my case. I've set up cron triggers for executing ping jobs and
those triggers actually invoke HTTP GET on my tapestry pages, so the app is
always warm.
On Wed, Aug 26, 2009 at 11:12, Onno Scheffers <on...@piraya.nl> wrote:
>
> @Dmitry
> Sorry for hijacking your thread like this. Tapestry on GAE looks very
> interesting to me.
> I was wondering how long it takes for the first page to render after the
> application has just been deployed/suspended. If I'm not mistaken, GAE will
> have cleaned up your instance if it isn't being used much and will have to
> restart the application.
> Applications made up of servlets and JSPs will be running very quickly, but
> I guess a framework like Tapestry that has to initialize a lot of services
> might take a bit longer?
>
>
> regards,
>
> Onno
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by Ulrich Stärk <ul...@spielviel.de>.
I think that's way too complicated. Keep it simple:
a) blacklist everything and let the user contribute filenames, file extensions or paths to some
whitelisting service (already having some reasonable defaults like .css, .js, .png, ...) which
AssetSource queries before returning an Asset
b) restrict the AssetSource to only return assets referenced in a component/page using @Path,
@IncludeJavaScriptLibrary, @IncludeStylesheet and the context: and asset: binding prefixes
Uli
On 26.08.2009 13:19 schrieb Thiago H. de Paula Figueiredo:
> Em Wed, 26 Aug 2009 04:12:29 -0300, Onno Scheffers <on...@piraya.nl>
> escreveu:
>
>> @Thiago
>> How about allowing absolutely nothing from the classpath/WEB-INF
>> initially?
>> Directory listing should also be disabled.
>
> I agree. My suggestion to TAP-815 was:
>
> "I would suggest to have a chain of command, each object in it receiving
> the requested URL and responding true (ok), false (file is forbidden) or
> null (this object doesn't handle this URL, ask the same thing to the
> next object. This chain of command terminator would be a very
> restrictive one."
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by Onno Scheffers <on...@piraya.nl>.
>
> I agree. My suggestion to TAP-815 was:
>
> "I would suggest to have a chain of command, each object in it receiving
> the requested URL and responding true (ok), false (file is forbidden) or
> null (this object doesn't handle this URL, ask the same thing to the next
> object. This chain of command terminator would be a very restrictive one."
Hi Thiago,
I have that issue in my watchlist, so I just read the discussion going on
there. I'm with Ulrich on this one though... and I just noticed you are as
well. Good to see we are all in agreement :P
regards,
Onno
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 26 Aug 2009 04:12:29 -0300, Onno Scheffers <on...@piraya.nl>
escreveu:
> @Thiago
> How about allowing absolutely nothing from the classpath/WEB-INF
> initially?
> Directory listing should also be disabled.
I agree. My suggestion to TAP-815 was:
"I would suggest to have a chain of command, each object in it receiving
the requested URL and responding true (ok), false (file is forbidden) or
null (this object doesn't handle this URL, ask the same thing to the next
object. This chain of command terminator would be a very restrictive one."
--
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: Running Tapestry 5.0.18 on Google App Engine
Posted by Onno Scheffers <on...@piraya.nl>.
> Everyone is invited to contribute to the solution by posting all the ways
we can have access to assets that shouldn't be available. ;)
@Thiago
How about allowing absolutely nothing from the classpath/WEB-INF initially?
Directory listing should also be disabled.
When a page or component comes along that explicitly asks for an asset, then
whitelist that asset before the markup is sent back to the browser. Then you
put developers in control over what gets whitelisted.
@Dmitry
Sorry for hijacking your thread like this. Tapestry on GAE looks very
interesting to me.
I was wondering how long it takes for the first page to render after the
application has just been deployed/suspended. If I'm not mistaken, GAE will
have cleaned up your instance if it isn't being used much and will have to
restart the application.
Applications made up of servlets and JSPs will be running very quickly, but
I guess a framework like Tapestry that has to initialize a lot of services
might take a bit longer?
regards,
Onno
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 25 Aug 2009 11:01:58 -0300, Christian Riedel
<ch...@gmx.net> escreveu:
> In the link I posted in my first reply, there are some T5.0.18 sites
> that don't list WEB-INF, in some you can find the hibernate.cfg.xml
> under /assets/, in some you don't.
> Some also seem to implement the workaround, so there isn't any directory
> listing.
As far as I can remember, Tapestry 5.0 had a different security bug than
5.1. Please let me know if I'm wrong.
> But hey, the *default* is, everybody can read your configurations! I
> found some database connection strings including username and passwords.
> That's not automatically a backdoor, but it makes certain activities a
> lot easier ;)
You're absolutely right. It should have been secure by default.
> Please, Thiago, Howard, any commiter: fix this! :)
Everyone is invited to contribute to the solution by posting all the ways
we can have access to assets that shouldn't be available. ;)
--
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: Running Tapestry 5.0.18 on Google App Engine
Posted by Christian Riedel <ch...@gmx.net>.
In the link I posted in my first reply, there are some T5.0.18 sites
that don't list WEB-INF, in some you can find the hibernate.cfg.xml
under /assets/, in some you don't.
Some also seem to implement the workaround, so there isn't any directory
listing.
But hey, the *default* is, everybody can read your configurations! I
found some database connection strings including username and passwords.
That's not automatically a backdoor, but it makes certain activities a
lot easier ;)
Please, Thiago, Howard, any commiter: fix this! :)
regards
christian
Thiago H. de Paula Figueiredo schrieb:
> Em Tue, 25 Aug 2009 10:25:21 -0300, Onno Scheffers <on...@piraya.nl>
> escreveu:
>
>> Apparently it does, since Christian also provided example-links.
>
> I stand corrected.
>
>> I just checked and I can also publicly access resources like the
>> web.xml and hibernate.cfg.xml on a webapp that is already in
>> production using Tapestry 5.0.18. This is a *VERY* high priority
>> security-issue with Tapestry IMO.
>
> Have you ever found some insecure resource URL that doesn't include
> WEB-INF on it?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 25 Aug 2009 10:25:21 -0300, Onno Scheffers <on...@piraya.nl>
escreveu:
> Apparently it does, since Christian also provided example-links.
I stand corrected.
> I just checked and I can also publicly access resources like the web.xml
> and hibernate.cfg.xml on a webapp that is already in production using
> Tapestry 5.0.18. This is a *VERY* high priority security-issue with
> Tapestry IMO.
Have you ever found some insecure resource URL that doesn't include
WEB-INF on it?
--
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: Running Tapestry 5.0.18 on Google App Engine
Posted by Onno Scheffers <on...@piraya.nl>.
>
> AFAIK, this issue doesn't affect T5.0.18, as it happens only with versioned
> assets, something that was introduced in T5.1.
Apparently it does, since Christian also provided example-links.
I just checked and I can also publicly access resources like the web.xml and
hibernate.cfg.xml on a webapp that is already in production using Tapestry
5.0.18. This is a *VERY* high priority security-issue with Tapestry IMO.
regards,
Onno
Re: Running Tapestry 5.0.18 on Google App Engine
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 25 Aug 2009 09:44:35 -0300, Christian Riedel
<ch...@gmx.net> escreveu:
> FYI you should (all) be aware of TAP-815*! Your assets** are readable
> for everybody!
AFAIK, this issue doesn't affect T5.0.18, as it happens only with
versioned assets, something that was introduced in T5.1.
--
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: Running Tapestry 5.0.18 on Google App Engine
Posted by Christian Riedel <ch...@gmx.net>.
FYI you should (all) be aware of TAP-815*! Your assets** are readable
for everybody!
It is certainly not as critical as in some pages named in this thread***
but in general it could cause some bad reputation for T5.
Apart from that I just can say: nice work! ;)
*jira ticket:
https://issues.apache.org/jira/browse/TAP5-815
**example asset
http://ping-service.appspot.com/assets/META-INF/persistence.xml
***
http://www.nabble.com/-REQUEST--Live-T5-web-sites%2C-quotes%2C-marketting-ts23050433s302.html#a23054798
easy workaround:
http://www.nabble.com/-T5--Security-of-files-in-the-classpath-ts11816097s302.html#a11816097
regards
christian
Dmitry Gusev schrieb:
> FYI
>
> Here is the running t5 app: http://ping-service.appspot.com/
>
> It uses T5.0.18 + Spring 3.0.0M4/JPA + Google
> Datastore/Mail/Cron/URLFetch/Google Accounts Security
>
> Works pretty well.
>
> I had to implement some hacks to develope with t5 on local dev server (t5
> error page refuse to work properly there by default, but works ok in
> appengine cloud), here is the solution:
>
> http://dmitrygusev.blogspot.com/2009/08/turn-java-security-manager-off-in.html
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org