cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: cocoon-view as possible security problem?
Date Fri, 21 Mar 2003 19:05:20 GMT
At 01:52 PM 3/21/2003, you wrote:
>On Fri, 21 Mar 2003, Geoff Howard wrote:
> > >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?
> >From my experience with PHP, here's how it works:
>You have a PHP script that a form posts a file to.  During the execution
>of the script, you have access to an object which represents the uploaded
>file.  The object also contains the name of the file on the client
>machine, the mime/type, the actual size of the file uploaded, and the
>temporary name of the file as it is stored on the server.
>The uploaded file only exists on the filesystem for the duration of the
>script, and if you want to actually save it, you need to move the temp
>file into a directory.  As soon as the script is done executing, PHP
>automatically removes the temporary file.  This seems to work out just
>fine, and I haven't seen any bad security problems with it so far.
>For further inspiration, check out [1]

Yes, this is on my list of things I'd like to get to - there was a 
discussion about it a month ago or so.  That is also a step in the right 
direction.  Most of that is already in place for us, except notably 
cleaning the file up on the way out.  I worked up a patch to CocoonServlet 
that did just that but someone had the good suggestion to modify the whole 
process to store either the files themselves in Request attributes (not 
back compatible unless you put them in the Request too) or the keys to the 
FilePart objects in as Request attributes.  Great idea that I'm hoping to 
work on, but have been quite busy at a new job. (launching rockets, 
according to SN ;) )

If anyone with more time wants to pursue that themselves, I'd gladly pass 
on what I was working on (though not sure any code remains).


I'll check this out later.


View raw message