tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David White <dw11...@onemail.at>
Subject Re: [jira] Resolved: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Date Sat, 19 Mar 2005 09:01:17 GMT
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

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.



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 <dw11610@onemail.at>

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

View raw message