tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Date Mon, 12 May 2003 17:34:24 GMT
So the issues are:
1. AJP/1.3 compatibility
2. Potential DoS

As far as DoS goes, with the previous behaviour any parameters POSTed 
would be persisted in the session until the authentication was completed 
or the session timed out.  Therefore, the same issue exists with both 
the old and new implementation. (a)

The size of the the POST is already limited by maxPostSize for both
FORM and CLIENT-CERT auth. Is the proposal to add another parameter to
the connector to optionally further limit the saved POST size when 
authenticating? (b)

Given (a), I don't see a significant difference in risk between the old 
and new behaviour. I am happy to mitigate this risk by implementing (b). 
As maxPostSize applies to any POST, including during CLIENT-CERT auth my 
own view is that the new parameter should apply only to the 
FormAuthenticator valve and should default to 0 (ie no data saved). -1 
would mean use whatever value is specified for maxPostSize and any value 
 >0 would be the limit unless maxPostSize was smaller in which case 
maxPostSize would override the new parameter. The docs for this 
parameter would include a health warning about the risks of permitting 
the saving of POSTed data during FORM authentication.

I obviously also need to look at AJP/1.3 compatibility. Any hints/tips 
gratefully received.

If these issues aren't resolved by the time of the next release, I'll
revert the saving the raw data part of the patch.


Bill Barker wrote:
> ----- Original Message ----- From: "Remy Maucherat" <>
> To: "Tomcat Developers List" <>
> Sent: Thursday, May 12, 2005 5:28 AM
> Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
>> Tim Funk wrote:
>>> Would it be worthwhile to use a new property?
>>> maxSavePostSize - The max size of a post to save. 0 for unlimited, -1 
>>> to disable saving post.
>>> Of course this doesn't mitigate a malicious person issuing many POSTS 
>>> under the configured threshold.
>> I think I disagree. Even if you are not trying to do a DoS, it is very 
>> easy to do it non intentionally if you save any post data (file upload).
>> We'd need to restrict saved POST size severely, as well as restrict 
>> more by default any form POST data.
> I agree.  I'd even be +1 to further restricting the saved body size for 
> CLIENT-CERT auth, and that one is only saved for the time of one 
> request. Since the body in a FORM auth is going to be saved for much 
> longer, it's even more important to restrict it.
> And this is even more important for mod_jk users, since they will never 
> get a chance to recover the data that they have posted :(.
>> Rémy

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message