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 Thu, 10 Mar 2005 08:55:03 GMT
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


Mime
View raw message