You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Nathan Kopp (JIRA)" <ta...@jakarta.apache.org> on 2005/03/08 17:18:55 UTC
[jira] Created: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Tapestry 3.0.2 asset service has security flaw
----------------------------------------------
Key: TAPESTRY-278
URL: http://issues.apache.org/jira/browse/TAPESTRY-278
Project: Tapestry
Type: Bug
Components: Framework
Versions: 3.0.2
Environment: Tomcat 5, JDK 1.4
Reporter: Nathan Kopp
The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
* View the web.xml file:
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
* View the tapestry.application file:
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
* View a raw JSP file:
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
* Download a few class files that are part of the application:
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Closed: (TAPESTRY-278) Tapestry 3.0.2 asset service has
security flaw
Posted by "Brian K. Wallace (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-278?page=all ]
Brian K. Wallace closed TAPESTRY-278:
-------------------------------------
> Tapestry 3.0.2 asset service has security flaw
> ----------------------------------------------
>
> Key: TAPESTRY-278
> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.0.2
> Environment: Tomcat 5, JDK 1.4
> Reporter: Nathan Kopp
> Assignee: Paul Ferraro
> Fix For: 3.0.3
> Attachments: AssetService.patch
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by "David Taylor (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-278?page=comments#action_60675 ]
David Taylor commented on TAPESTRY-278:
---------------------------------------
It seems the best solution to this problem might be to add a mechanism that forces the developer to explicitly declare which resources can be accessed by the asset service. This could take the form of descriptor file(s) stored in a central location (e.g. META-INF dir) and/or adjacent to the classpath resources being served. The descriptor would declare accessible assets individually or by wildcard (maybe a regex). Anything not explicitly allowed would be protected. This approach is similar to the approach used for Apache .htaccess files.
I think this model would also work for packaged librarys such as Contrib since you would simply need to add a security descriptor to the resource directories. Of course, to keep things flexible, it would be nice to make this mechanism extensible for special cases. I for one can think of some special cases such as dynamically generated assests.
Any thoughts?
David
> Tapestry 3.0.2 asset service has security flaw
> ----------------------------------------------
>
> Key: TAPESTRY-278
> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.0.2
> Environment: Tomcat 5, JDK 1.4
> Reporter: Nathan Kopp
> Attachments: AssetService.patch
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by David White <dw...@onemail.at>.
On Sun, 2005-03-20 at 13:43 -0500, Nathan Kopp wrote:
> Robert Zeigler <rd...@u.arizona.edu> wrote...
> >
> > Meaning no offense, but, this idea sounds like hell to me. Do I, or do
> > you, really want to waste time editing a config file somewhere because I
> > added three new images? Or 1000? Or 2000? I maintain an app right now
> > which contains over 3000 images so the numbers aren't far-fetched.
>
> First, thanks for Howard for coming up with a creative solution quickly,
> even if it's not completely satisfactory for everyone.
>
> Two opinions/thoughts:
> 1) Personally, I think that, unless otherwise configured, the asset service
> should follow the standard web application protocol and (by default) hide
> everything in the WEB-INF folder. This would mean not using a classloader
> for loading assets (as suggested by David White). Of course, this would
> break backwards compatibility. I think you could whitelist certain folders
> within WEB-INF to allow them to be visible, but I think the developer should
> be forced to intentionally do this, since it is nonstandard and potentiall
> unsafe. At least that's how I see it.
>
I think anything else is asking for serious trouble. Imagine if someone
were to do a firewall/router configuration interface in Tapestry (this
is pretty close to the sort of thing my project is working on, but
possibly even *more* sensitive).
> 2) Aren't all assets referenced in some way by components, before the user
> requests them?
Thanks for mentioning this. I saw this auditing the code and am pursuing
this possibility to solve the problem in a reasonable way. A diff to the
3-0-branch as of 2005-03-16 is on its way.
I'll be able to test this tomorrow (CET), hopefully a patch against this
version will be forthcoming on this list.
David WHITE
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by Nathan Kopp <nk...@mailshell.com>.
Robert Zeigler <rd...@u.arizona.edu> wrote...
>
> Meaning no offense, but, this idea sounds like hell to me. Do I, or do
> you, really want to waste time editing a config file somewhere because I
> added three new images? Or 1000? Or 2000? I maintain an app right now
> which contains over 3000 images so the numbers aren't far-fetched.
First, thanks for Howard for coming up with a creative solution quickly,
even if it's not completely satisfactory for everyone.
Two opinions/thoughts:
1) Personally, I think that, unless otherwise configured, the asset service
should follow the standard web application protocol and (by default) hide
everything in the WEB-INF folder. This would mean not using a classloader
for loading assets (as suggested by David White). Of course, this would
break backwards compatibility. I think you could whitelist certain folders
within WEB-INF to allow them to be visible, but I think the developer should
be forced to intentionally do this, since it is nonstandard and potentiall
unsafe. At least that's how I see it.
2) Aren't all assets referenced in some way by components, before the user
requests them? If so, then a whitelist could be automatically generated at
run time by the components that expose these assets. There should be no
need manually configure the whitelist. Of course, in some applications this
whitelist could grow quite large and consume lots of memory, so things
wouldn't necessarily have to stay in the whitelist indefinitely... next time
a component exposes an asset, the asset would be once again added to the
whitelist.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by David White <dw...@onemail.at>.
On Sat, 2005-03-19 at 11:35 -0700, Robert Zeigler wrote:
> David White wrote:
> > Please reconsider this solution. A project I am involved in is using
> > Tapestry on a resource-constrained device, and noone was happy about
> > calculating an MD5 on assets on every access.
>
> How would you be calculating an md5 on assets on every access?
> I haven't looked at the patch in detail, but my understanding is that
> you compute the md5 once, the first time the asset is accessed. The has
> is then stored. The next time the asset is accessed, you supply the
> stored md5. Even if you're doing the comparison, you're essentially
> comparing the request parameter with the previously computed and cached
> hash; it's a simple string comparison, rather than a recompute of the hash.
>
Checking the code, it is trivially possible to produce an (in theory)
infinite number of distinct yet equivalent URL's that will force a
recompute-and-cache, e.g. for /a/b/c.gif thanks to our friends '.' and
'..'. DoS, anyone?
> <snip>
> > My suggestion is the following:
> >
> > In a Tapestry deployment, require that resources accessible to the asset
> > service be explicitly declared in the application specification.
> > Anything that is not on the asset whitelist is invisible to the asset
> > service.
> </snip>
>
> Meaning no offense, but, this idea sounds like hell to me. Do I, or do
> you, really want to waste time editing a config file somewhere because I
> added three new images? Or 1000? Or 2000? I maintain an app right now
> which contains over 3000 images so the numbers aren't far-fetched.
> And
> don't tell me that regular expressions are the answer, either.
> 1) It's difficult to come up with an expression (or set of expressions)
> that covers all valid files and which also excludes all invalid files.
> 2) Even conceding that it's possible to accomplish #1, should users be
> required to master regex. before being able to utilize assets?
3) It may fail catastrophically if the user has not mastered regexes, by
allowing directory traversal sequences and possibly other nastiness in
calls to the asset service.
No, regex or wildcards WILL NOT make the problem go away.
Does this app really pack many thousands of images into the WAR? That
sounds quite unpleasant to deal with. How does it manage so many
pictures? What can be done in this app about broken or inappropriate
content?
My $0.02 -- don't use the ClassLoader for this kind of heavy lifting. It
sounds like you need a custom service that e.g. pulls the images from a
database as BLOBs or something.
>
> As noted before, the md5 has is only computed once, anyway, and you can
> override the hash mechanism to reduce computational complexity and costs.
>
> Robert
Reducing the size of the hash code makes brute-force attacks possible.
This is very, very bad. Remember, many, many Java implementations can
easily escape from their classpath with directory traversal sequences.
Consider the implications of this.
In the particular project I am working on, the impact of this bug is
terrifying. The problem needs to be solved correctly, and not with half
measures.
I mean no offence, and I hope you and other Tapestry contributors can
see this objection as constructive criticism. Thanks for your attention.
David WHITE
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by Robert Zeigler <rd...@u.arizona.edu>.
David White wrote:
> Please reconsider this solution. A project I am involved in is using
> Tapestry on a resource-constrained device, and noone was happy about
> calculating an MD5 on assets on every access.
How would you be calculating an md5 on assets on every access?
I haven't looked at the patch in detail, but my understanding is that
you compute the md5 once, the first time the asset is accessed. The has
is then stored. The next time the asset is accessed, you supply the
stored md5. Even if you're doing the comparison, you're essentially
comparing the request parameter with the previously computed and cached
hash; it's a simple string comparison, rather than a recompute of the hash.
<snip>
> My suggestion is the following:
>
> In a Tapestry deployment, require that resources accessible to the asset
> service be explicitly declared in the application specification.
> Anything that is not on the asset whitelist is invisible to the asset
> service.
</snip>
Meaning no offense, but, this idea sounds like hell to me. Do I, or do
you, really want to waste time editing a config file somewhere because I
added three new images? Or 1000? Or 2000? I maintain an app right now
which contains over 3000 images so the numbers aren't far-fetched. And
don't tell me that regular expressions are the answer, either.
1) It's difficult to come up with an expression (or set of expressions)
that covers all valid files and which also excludes all invalid files.
2) Even conceding that it's possible to accomplish #1, should users be
required to master regex. before being able to utilize assets?
As noted before, the md5 has is only computed once, anyway, and you can
override the hash mechanism to reduce computational complexity and costs.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by "matthew c. mead" <m-...@goof.com>.
Howard has talked about this fix in several posts recently.
It calculates the hash once for the life of the engine and caches it.
It is also very easy to override this and plug in your own
ResourceChecksumSource that performs a computationally inconsequential
calculation instead. Several readers have suggested a CRC32 checksum or
a MD5 on the first few KB of the file.
-matt
David White wrote:
>Please reconsider this solution. A project I am involved in is using
>Tapestry on a resource-constrained device, and noone was happy about
>calculating an MD5 on assets on every access.
>
>I think the root problem here is that the asset service ends up
>delegating to at least one ClassLoader via the IResourceResolver
>interface. This overloading of functionality permits the service to
>access pretty much any resource it wants. If the underlying ClassLoader
>implementation is permissive enough, this can include directory
>traversals, and in many cases even directory browsing! This solution is
>computationally expensive and seems to miss the point entirely.
>
>My suggestion is the following:
>
>In a Tapestry deployment, require that resources accessible to the asset
>service be explicitly declared in the application specification.
>Anything that is not on the asset whitelist is invisible to the asset
>service.
>
>This solves a number of problems with the asset service, including the
>potential to download class files and specifications which do not
>concern the asset service.
>
>Thanks,
>
>David WHITE
>
>On Thu, 2005-03-17 at 19:48 +0100, Paul Ferraro (JIRA) wrote:
>
>
>> [ http://issues.apache.org/jira/browse/TAPESTRY-278?page=history ]
>>
>>Paul Ferraro resolved TAPESTRY-278:
>>-----------------------------------
>>
>> Resolution: Fixed
>> Fix Version: 3.0.3
>>
>>Fixed security flaw by requiring all asset service requests to specify a correct resource checksum. Default checksum implementation uses Hex encoded MD5 hash. Implementation may be overridden by re-implementing AbstractEngine.createResourceChecksumSource(). Fix is based largely on new code in 3.1 branch.
>>
>>
>>
>>>Tapestry 3.0.2 asset service has security flaw
>>>----------------------------------------------
>>>
>>> Key: TAPESTRY-278
>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>>> Project: Tapestry
>>> Type: Bug
>>> Components: Framework
>>> Versions: 3.0.2
>>> Environment: Tomcat 5, JDK 1.4
>>> Reporter: Nathan Kopp
>>> Assignee: Paul Ferraro
>>> Fix For: 3.0.3
>>> Attachments: AssetService.patch
>>>
>>>The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
>>>The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
>>>Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
>>>* View the web.xml file:
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
>>>* View the tapestry.application file:
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
>>>* View a raw JSP file:
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
>>>* Download a few class files that are part of the application:
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by David White <dw...@onemail.at>.
Please reconsider this solution. A project I am involved in is using
Tapestry on a resource-constrained device, and noone was happy about
calculating an MD5 on assets on every access.
I think the root problem here is that the asset service ends up
delegating to at least one ClassLoader via the IResourceResolver
interface. This overloading of functionality permits the service to
access pretty much any resource it wants. If the underlying ClassLoader
implementation is permissive enough, this can include directory
traversals, and in many cases even directory browsing! This solution is
computationally expensive and seems to miss the point entirely.
My suggestion is the following:
In a Tapestry deployment, require that resources accessible to the asset
service be explicitly declared in the application specification.
Anything that is not on the asset whitelist is invisible to the asset
service.
This solves a number of problems with the asset service, including the
potential to download class files and specifications which do not
concern the asset service.
Thanks,
David WHITE
On Thu, 2005-03-17 at 19:48 +0100, Paul Ferraro (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/TAPESTRY-278?page=history ]
>
> Paul Ferraro resolved TAPESTRY-278:
> -----------------------------------
>
> Resolution: Fixed
> Fix Version: 3.0.3
>
> Fixed security flaw by requiring all asset service requests to specify a correct resource checksum. Default checksum implementation uses Hex encoded MD5 hash. Implementation may be overridden by re-implementing AbstractEngine.createResourceChecksumSource(). Fix is based largely on new code in 3.1 branch.
>
> > Tapestry 3.0.2 asset service has security flaw
> > ----------------------------------------------
> >
> > Key: TAPESTRY-278
> > URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> > Project: Tapestry
> > Type: Bug
> > Components: Framework
> > Versions: 3.0.2
> > Environment: Tomcat 5, JDK 1.4
> > Reporter: Nathan Kopp
> > Assignee: Paul Ferraro
> > Fix For: 3.0.3
> > Attachments: AssetService.patch
> >
> > The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> > The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> > Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> > * View the web.xml file:
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> > * View the tapestry.application file:
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> > * View a raw JSP file:
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> > * Download a few class files that are part of the application:
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> > http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>
--
David White <dw...@onemail.at>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by "Paul Ferraro (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-278?page=history ]
Paul Ferraro resolved TAPESTRY-278:
-----------------------------------
Resolution: Fixed
Fix Version: 3.0.3
Fixed security flaw by requiring all asset service requests to specify a correct resource checksum. Default checksum implementation uses Hex encoded MD5 hash. Implementation may be overridden by re-implementing AbstractEngine.createResourceChecksumSource(). Fix is based largely on new code in 3.1 branch.
> Tapestry 3.0.2 asset service has security flaw
> ----------------------------------------------
>
> Key: TAPESTRY-278
> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.0.2
> Environment: Tomcat 5, JDK 1.4
> Reporter: Nathan Kopp
> Assignee: Paul Ferraro
> Fix For: 3.0.3
> Attachments: AssetService.patch
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by Robert Zeigler <rd...@u.arizona.edu>.
Erik Hatcher wrote:
> On Mar 9, 2005, at 8:21 PM, Robert Zeigler wrote:
>
>> Erik Hatcher wrote:
>>
>>> Prodding this issue.... thoughts? What do we want to do about
>>> this? Is blocking on file extension as a built-in patch good
>>> enough? What extensions should be allowed? Block paths with ".."
>>> also? Other stop-gap approaches?
>>
>>
>> I'm really not fond of blocking on file extensions.
>> Blocking paths with .. is a start, but still circumventable.
>> As I understand it, the asset service should provide access to assets
>> in any of the "context" subdirectories, except for WEB-INF, right?
>> (ie: MyWebApp/img.jpg, MyWebApp/images/img.jpg should both be
>> accessible via the asset service, but MyWebApp/WEB-INF/img.jpg should
>> not).
>> Since (if? =) this is the case, why not examine the directory
>> structure of the asset? You can do a recursive check to make sure
>> that the asset is not in a forbidden directory. Thoughts?
>
>
> The true beauty (and thus security hole) of the asset service is that
> it is designed to serve up content from libraries within the classpath.
> Consider DatePicker and its calendar icon and JavaScript code. You
> didn't put either of those above WEB-INF, did you? :) These are
> within the contrib JAR in WEB-INF/lib.
>
Heh. Sorry, too tired last night when I wrote in, I guess, and
completely forgot about private assets. =) I'll have to think on this a
bit.
> Please elaborate on how blocking with ".." is circumventable. (this
> would be a good start on a test case)
>
I read an interesting article on bugtraq at one point describing methods
whereby the .. can be cleverly escaped such that when all is said and
done, you still end up with a file with .. in the path. I don't remember
all of the details offhand; I'll see if I can dig up the article.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Mar 9, 2005, at 8:21 PM, Robert Zeigler wrote:
> Erik Hatcher wrote:
>> Prodding this issue.... thoughts? What do we want to do about this?
>> Is blocking on file extension as a built-in patch good enough?
>> What extensions should be allowed? Block paths with ".." also?
>> Other stop-gap approaches?
>
> I'm really not fond of blocking on file extensions.
> Blocking paths with .. is a start, but still circumventable.
> As I understand it, the asset service should provide access to assets
> in any of the "context" subdirectories, except for WEB-INF, right?
> (ie: MyWebApp/img.jpg, MyWebApp/images/img.jpg should both be
> accessible via the asset service, but MyWebApp/WEB-INF/img.jpg should
> not).
> Since (if? =) this is the case, why not examine the directory
> structure of the asset? You can do a recursive check to make sure that
> the asset is not in a forbidden directory. Thoughts?
The true beauty (and thus security hole) of the asset service is that
it is designed to serve up content from libraries within the classpath.
Consider DatePicker and its calendar icon and JavaScript code. You
didn't put either of those above WEB-INF, did you? :) These are
within the contrib JAR in WEB-INF/lib.
Please elaborate on how blocking with ".." is circumventable. (this
would be a good start on a test case)
Erik
> Robert
>
>> Howard mentioned via IM chat that adding an MD5 of the asset to the
>> URL and checking it before serving is something we should add
>> eventually.
>> Erik
>> On Mar 9, 2005, at 5:21 AM, Erik Hatcher wrote:
>>> I'm bringing this issue to the e-mail list. Many of us already knew
>>> this existed and it has been discussed here before but I've always
>>> used other techniques to block this hole. I agree its serious and
>>> needs to be corrected. What do folks suggest as the proper fix?
>>> Preventing ".." would be a quick and dirty way to stop path
>>> snooping, but also blocking all but a set of extensions would be
>>> needed.
>>>
>>> There are some workarounds:
>>>
>>> * use the asset externalization feature so that asset serving is
>>> from the container or web server rather than the asset service
>>> directly
>>> * use a servlet filter to block everything but .jpg/.gif/.png.
>>> Interestingly, my clean URL servlet filter on lucenebook.com thwarts
>>> the security hole.
>>>
>>> Howard - what do you see has a fix for this? This warrants a 3.0.3
>>> release IMO.
>>>
>>> Erik
>>>
>>>
>>> On Mar 9, 2005, at 3:58 AM, Danny Angus (JIRA) wrote:
>>>
>>>> [ http://issues.apache.org/jira/browse/TAPESTRY-278?
>>>> page=comments#action_60487 ]
>>>>
>>>> Danny Angus commented on TAPESTRY-278:
>>>> --------------------------------------
>>>>
>>>> This is a very significant issue which needs addressed as soon as
>>>> possible.
>>>>
>>>>> Tapestry 3.0.2 asset service has security flaw
>>>>> ----------------------------------------------
>>>>>
>>>>> Key: TAPESTRY-278
>>>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>>>>> Project: Tapestry
>>>>> Type: Bug
>>>>> Components: Framework
>>>>> Versions: 3.0.2
>>>>> Environment: Tomcat 5, JDK 1.4
>>>>> Reporter: Nathan Kopp
>>>>
>>>>
>>>>>
>>>>> The asset service can be used to view files that should not be
>>>>> visible. This could expose important resources, including
>>>>> database passwords and connection information.
>>>>> The asset service appears to expose any file relative to the
>>>>> classpath, and you can even use the ".." operator to go backwards,
>>>>> down into WEB-INF in general.
>>>>> Here are some examples. They were tested on a demo application
>>>>> which is often available on the web, but they've been "cleaned,"
>>>>> so they don't point to a real server anymore:
>>>>> * View the web.xml file:
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2F..%2Fweb.xml
>>>>> * View the tapestry.application file:
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2F..%2Ftapestry.application
>>>>> * View a raw JSP file:
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2F..%2F..%2F404.jsp
>>>>> * Download a few class files that are part of the application:
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>>
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> If you think it was sent incorrectly contact one of the
>>>> administrators:
>>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>>> -
>>>> If you want more information on JIRA, or have a bug to report see:
>>>> http://www.atlassian.com/software/jira
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:
>>>> tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by Robert Zeigler <rd...@u.arizona.edu>.
Erik Hatcher wrote:
> Prodding this issue.... thoughts? What do we want to do about this?
> Is blocking on file extension as a built-in patch good enough? What
> extensions should be allowed? Block paths with ".." also? Other
> stop-gap approaches?
I'm really not fond of blocking on file extensions.
Blocking paths with .. is a start, but still circumventable.
As I understand it, the asset service should provide access to assets
in any of the "context" subdirectories, except for WEB-INF, right?
(ie: MyWebApp/img.jpg, MyWebApp/images/img.jpg should both be accessible
via the asset service, but MyWebApp/WEB-INF/img.jpg should not).
Since (if? =) this is the case, why not examine the directory structure
of the asset? You can do a recursive check to make sure that the asset
is not in a forbidden directory. Thoughts?
Robert
>
> Howard mentioned via IM chat that adding an MD5 of the asset to the URL
> and checking it before serving is something we should add eventually.
>
> Erik
>
>
>
> On Mar 9, 2005, at 5:21 AM, Erik Hatcher wrote:
>
>> I'm bringing this issue to the e-mail list. Many of us already knew
>> this existed and it has been discussed here before but I've always
>> used other techniques to block this hole. I agree its serious and
>> needs to be corrected. What do folks suggest as the proper fix?
>> Preventing ".." would be a quick and dirty way to stop path snooping,
>> but also blocking all but a set of extensions would be needed.
>>
>> There are some workarounds:
>>
>> * use the asset externalization feature so that asset serving is
>> from the container or web server rather than the asset service directly
>> * use a servlet filter to block everything but .jpg/.gif/.png.
>> Interestingly, my clean URL servlet filter on lucenebook.com thwarts
>> the security hole.
>>
>> Howard - what do you see has a fix for this? This warrants a 3.0.3
>> release IMO.
>>
>> Erik
>>
>>
>> On Mar 9, 2005, at 3:58 AM, Danny Angus (JIRA) wrote:
>>
>>> [ http://issues.apache.org/jira/browse/TAPESTRY-278?
>>> page=comments#action_60487 ]
>>>
>>> Danny Angus commented on TAPESTRY-278:
>>> --------------------------------------
>>>
>>> This is a very significant issue which needs addressed as soon as
>>> possible.
>>>
>>>> Tapestry 3.0.2 asset service has security flaw
>>>> ----------------------------------------------
>>>>
>>>> Key: TAPESTRY-278
>>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>>>> Project: Tapestry
>>>> Type: Bug
>>>> Components: Framework
>>>> Versions: 3.0.2
>>>> Environment: Tomcat 5, JDK 1.4
>>>> Reporter: Nathan Kopp
>>>
>>>
>>>>
>>>> The asset service can be used to view files that should not be
>>>> visible. This could expose important resources, including database
>>>> passwords and connection information.
>>>> The asset service appears to expose any file relative to the
>>>> classpath, and you can even use the ".." operator to go backwards,
>>>> down into WEB-INF in general.
>>>> Here are some examples. They were tested on a demo application
>>>> which is often available on the web, but they've been "cleaned," so
>>>> they don't point to a real server anymore:
>>>> * View the web.xml file:
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2F..%2Fweb.xml
>>>> * View the tapestry.application file:
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2F..%2Ftapestry.application
>>>> * View a raw JSP file:
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2F..%2F..%2F404.jsp
>>>> * Download a few class files that are part of the application:
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the administrators:
>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>> -
>>> If you want more information on JIRA, or have a bug to report see:
>>> http://www.atlassian.com/software/jira
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Prodding this issue.... thoughts? What do we want to do about this?
Is blocking on file extension as a built-in patch good enough? What
extensions should be allowed? Block paths with ".." also? Other
stop-gap approaches?
Howard mentioned via IM chat that adding an MD5 of the asset to the URL
and checking it before serving is something we should add eventually.
Erik
On Mar 9, 2005, at 5:21 AM, Erik Hatcher wrote:
> I'm bringing this issue to the e-mail list. Many of us already knew
> this existed and it has been discussed here before but I've always
> used other techniques to block this hole. I agree its serious and
> needs to be corrected. What do folks suggest as the proper fix?
> Preventing ".." would be a quick and dirty way to stop path snooping,
> but also blocking all but a set of extensions would be needed.
>
> There are some workarounds:
>
> * use the asset externalization feature so that asset serving is from
> the container or web server rather than the asset service directly
> * use a servlet filter to block everything but .jpg/.gif/.png.
> Interestingly, my clean URL servlet filter on lucenebook.com thwarts
> the security hole.
>
> Howard - what do you see has a fix for this? This warrants a 3.0.3
> release IMO.
>
> Erik
>
>
> On Mar 9, 2005, at 3:58 AM, Danny Angus (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/TAPESTRY-278?
>> page=comments#action_60487 ]
>>
>> Danny Angus commented on TAPESTRY-278:
>> --------------------------------------
>>
>> This is a very significant issue which needs addressed as soon as
>> possible.
>>
>>> Tapestry 3.0.2 asset service has security flaw
>>> ----------------------------------------------
>>>
>>> Key: TAPESTRY-278
>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>>> Project: Tapestry
>>> Type: Bug
>>> Components: Framework
>>> Versions: 3.0.2
>>> Environment: Tomcat 5, JDK 1.4
>>> Reporter: Nathan Kopp
>>
>>>
>>> The asset service can be used to view files that should not be
>>> visible. This could expose important resources, including database
>>> passwords and connection information.
>>> The asset service appears to expose any file relative to the
>>> classpath, and you can even use the ".." operator to go backwards,
>>> down into WEB-INF in general.
>>> Here are some examples. They were tested on a demo application
>>> which is often available on the web, but they've been "cleaned," so
>>> they don't point to a real server anymore:
>>> * View the web.xml file:
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2F..%2Fweb.xml
>>> * View the tapestry.application file:
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2F..%2Ftapestry.application
>>> * View a raw JSP file:
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2F..%2F..%2F404.jsp
>>> * Download a few class files that are part of the application:
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> If you want more information on JIRA, or have a bug to report see:
>> http://www.atlassian.com/software/jira
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I'm bringing this issue to the e-mail list. Many of us already knew
this existed and it has been discussed here before but I've always used
other techniques to block this hole. I agree its serious and needs to
be corrected. What do folks suggest as the proper fix? Preventing
".." would be a quick and dirty way to stop path snooping, but also
blocking all but a set of extensions would be needed.
There are some workarounds:
* use the asset externalization feature so that asset serving is from
the container or web server rather than the asset service directly
* use a servlet filter to block everything but .jpg/.gif/.png.
Interestingly, my clean URL servlet filter on lucenebook.com thwarts
the security hole.
Howard - what do you see has a fix for this? This warrants a 3.0.3
release IMO.
Erik
On Mar 9, 2005, at 3:58 AM, Danny Angus (JIRA) wrote:
> [
> http://issues.apache.org/jira/browse/TAPESTRY-278?
> page=comments#action_60487 ]
>
> Danny Angus commented on TAPESTRY-278:
> --------------------------------------
>
> This is a very significant issue which needs addressed as soon as
> possible.
>
>> Tapestry 3.0.2 asset service has security flaw
>> ----------------------------------------------
>>
>> Key: TAPESTRY-278
>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>> Project: Tapestry
>> Type: Bug
>> Components: Framework
>> Versions: 3.0.2
>> Environment: Tomcat 5, JDK 1.4
>> Reporter: Nathan Kopp
>
>>
>> The asset service can be used to view files that should not be
>> visible. This could expose important resources, including database
>> passwords and connection information.
>> The asset service appears to expose any file relative to the
>> classpath, and you can even use the ".." operator to go backwards,
>> down into WEB-INF in general.
>> Here are some examples. They were tested on a demo application which
>> is often available on the web, but they've been "cleaned," so they
>> don't point to a real server anymore:
>> * View the web.xml file:
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2F..%2Fweb.xml
>> * View the tapestry.application file:
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2F..%2Ftapestry.application
>> * View a raw JSP file:
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2F..%2F..%2F404.jsp
>> * Download a few class files that are part of the application:
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by "Danny Angus (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-278?page=comments#action_60487 ]
Danny Angus commented on TAPESTRY-278:
--------------------------------------
This is a very significant issue which needs addressed as soon as possible.
> Tapestry 3.0.2 asset service has security flaw
> ----------------------------------------------
>
> Key: TAPESTRY-278
> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.0.2
> Environment: Tomcat 5, JDK 1.4
> Reporter: Nathan Kopp
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Updated: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by "gustav spellauge (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-278?page=history ]
gustav spellauge updated TAPESTRY-278:
--------------------------------------
Attachment: AssetService.patch
here is a quick patch for version 3.0.2 (14.02.2005) which works for us.
maybe the list of exposed mimetypes needs to be extended.
> Tapestry 3.0.2 asset service has security flaw
> ----------------------------------------------
>
> Key: TAPESTRY-278
> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.0.2
> Environment: Tomcat 5, JDK 1.4
> Reporter: Nathan Kopp
> Attachments: AssetService.patch
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Assigned: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by "Paul Ferraro (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-278?page=history ]
Paul Ferraro reassigned TAPESTRY-278:
-------------------------------------
Assign To: Paul Ferraro
> Tapestry 3.0.2 asset service has security flaw
> ----------------------------------------------
>
> Key: TAPESTRY-278
> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.0.2
> Environment: Tomcat 5, JDK 1.4
> Reporter: Nathan Kopp
> Assignee: Paul Ferraro
> Attachments: AssetService.patch
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org