On 08/05/2012 10:28, André Warnier wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Mark,
>>
>> On 5/7/12 5:21 PM, Mark Thomas wrote:
>>>> Christopher Schultz wrote:
>>> Tomcat only processes these requests for Servlet 3.0 file upload
>>> and there are already sufficient limits in place for that case to
>>> prevent a DoS.
>>
>> Aah, right: multipart is only supported if the servlet has been marked
>> as such, and therefore the developer knows to expect large mounts of
>> data (and can configure such limits).
>>
>> The wildcard is the "casual multipart parsing" which allows any
>> multipart request to be parsed without regard for such limits. Any
>> limits (data size) imposed on the connector will be used in those
>> cases, but "maximum number of parameters" is not one of them. I should
>> probably update the documentation for that feature to make a note of
>> this caveat.
>>
> 
> From the documentation of Commons/fileUpload, it would seem rather
> simple - for a Java guru - to implement a counter while processing the
> POSTed parameters, and ignore what is above maxParameterCount :
> 
> Sample code from http://commons.apache.org/fileupload/using.html :
> 
> // Process the uploaded items
> Iterator iter = items.iterator();
> while (iter.hasNext()) {
>     FileItem item = (FileItem) iter.next();
> 
>     if (item.isFormField()) {
>         processFormField(item);
>     } else {
>         processUploadedFile(item);
>     }
> }
> 
> (Maybe the "items" object above already has a "size" or "length" method,
> avoiding the counter logic altogether)
> 
> Of course by then, the POST has already been parsed, so I don't know if
> this would help a lot to avoid a DOS attack.
> But the maximum acceptable total size of the POST can be specified in
> advance, to avoid this.  After all, if someone wants to allow POSTs with
> 10,000 small parameters, then why not ?
> 
> I do not understand on the other hand the OP's later reference to a
> "hash collision". That sounds like a JVM issue, rather than a
> specifically Tomcat one, no ?

It is a JVM issue (in my view and many others) but one Oracle has chosen
not to fix.

maxParameterCount was put in place as a mitigation for this issue. It
looks like the OP may have a valid point regarding multi-part requests -
at least as far as the Servlet 3.0 upload code is concerned. I need to
do review the code to see exactly what is going on. Outside of Servlet
3.0 file upload, I don't believe it is a Tomcat concern.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to