cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: cocoon-view as possible security problem?
Date Fri, 21 Mar 2003 13:33:36 GMT
Geoff Howard wrote:

>>> By the way, I think there are bigger security problems in cocoon...
>>
<snip/>

> Also, is cocoon-reload still enabled by default?  seems a wget in a 
> loop with ?cocoon-reload=true could put a site in a world of hurt... 
> (by the way, last time I checked Jetty/Cocoon cvs is barfing on that..) 


With jetty, try http://localhost:8888?cocoon-reload=true - without '/' 
symbol. Jetty is ... different ... from other engines.


> I've worked on the multipart file uploads because I felt the original 
> status posed security/abuse issues.  It's now at a better point but I 
> think there are still some issues I'm not (at an RF level) convinced 
> are OK.  IIRC the default is now to allow "in-memory" uploads only 
> which is a step better. 


Is it? With in-memory upload you can get to OutOfMemory exceptions and 
potentially corrupt cocoon instance. With file uploads, you can create 
100Mb file systems which you can fill up but you won't disturb 
functionality of the server. I don't see how in-memory uploads are more 
secure; I see them as *less* secure.

And, of course, best approach is no uploads at all :)

<snip/>

> One I'd really like to look into is places where directory traversal 
> could be successful, depending on your matchers. 


That's might be real security issue.

Vadim



Mime
View raw message