On 08/05/2012 10:56, Mark Thomas wrote: > 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.
Yep, a one line fix was required. Fixed in trunk and 7.0.x and will be in 7.0.28 omwards. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
