tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Taylor (JIRA)" <tapestry-...@jakarta.apache.org>
Subject [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Date Sat, 12 Mar 2005 02:05:53 GMT
     [ 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?


> 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:
If you want more information on JIRA, or have a bug to report see:

To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message