Return-Path: 
 <cocoon-dev-return-38950-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 50366 invoked by uid 500); 21 Mar 2003 18:45:28 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 50351 invoked from network); 21 Mar 2003 18:45:27 -0000
Received: from unknown (HELO host.leverageweb.com) (64.91.232.157)
  by daedalus.apache.org with SMTP; 21 Mar 2003 18:45:27 -0000
Received: from dhcp205162.hq.af.mil ([134.205.205.162]
 helo=SGMIKHPOLDHAM.leverageweb.com)
	by host.leverageweb.com with esmtp (Exim 3.36 #1)
	id 18wRXH-00011C-00
	for cocoon-dev@xml.apache.org; Fri, 21 Mar 2003 13:46:35 -0500
Message-Id: <5.2.0.9.0.20030321132637.00a6ade8@leverageweb.com>
X-Sender: cocoon@leverageweb.com@leverageweb.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 21 Mar 2003 13:45:27 -0500
To: cocoon-dev@xml.apache.org
From: Geoff Howard <cocoon@leverageweb.com>
Subject: Re: cocoon-view as possible security problem?
In-Reply-To: <3E7B14B0.5020206@verizon.net>
References: <5.2.0.9.0.20030321074151.00addb98@leverageweb.com>
 <5.2.0.9.0.20030321071628.00a6ac08@leverageweb.com>
 <3E7AC617.4050005@apache.org>
 <20030320161105.N214-100000@neuagency.com>
 <3E7AC617.4050005@apache.org>
 <5.2.0.9.0.20030321071628.00a6ac08@leverageweb.com>
 <5.2.0.9.0.20030321074151.00addb98@leverageweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.leverageweb.com
X-AntiAbuse: Original Domain - xml.apache.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - leverageweb.com
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

At 08:33 AM 3/21/2003, you wrote:
>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.

Well, in combination with the max-upload-size parameter (or whatever it's 
called) I felt that better.  If I can cause the request to ignore multipart 
files bigger than xMB, that seems to mitigate the risk.  But that's worth 
some discussion.  My worry with autosaving all files is 1) I can purposely 
fill up your hard drive, given time. 2) Could a user more clever than I 
create a POST request that would cause a file to be placed somewhere other 
than the upload dir?

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

Well, you were probably half kidding/half serious.  Obviously, if my 
application doesn't use any uploads I should disable them in web.xml.  But 
right now, it's all or nothing: I either allow all users to upload _on any 
page_ (if they create a form that posts to any url in cocoon's space), or I 
totally disallow uploads.  I've been thinking through enabling configs for 
resource-based, or even authentication-based restrictions for 
uploads.  What would others think?

Geoff