tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Date Wed, 09 Mar 2005 10:21:07 GMT
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


Mime
View raw message