Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Date: 1 Mar 2004 09:33:50 -0000
Message-ID: <20040301093350.23449.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 27327] New:  -
    tie content length of form fields posted with struts-validator maxlength
 attribute or alike

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27327>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27327

tie content length of form fields posted with struts-validator maxlength attribute or alike

           Summary: tie content length of form fields posted with struts-
                    validator maxlength attribute or alike
           Product: Tomcat 5
           Version: 5.0.0
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Unknown
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: hauser@acm.org


eventually, DOS attachs might move from syn flooding to the application layer as
now seen for example by the decompression bombs
(http://www.aerasec.de/security/advisories/decompression-bomb-vulnerability.html).

Therefore, the concept implemented in most current httpd's is to first accept
anything of ANY SIZE and only afterwards (provided the server didn't blow up
already with "out-of-memory" - see Bug 22633 [maxFileSize not reaching GUI in
graceful way] and Bug 27143 [proactive management of low memory situations])
e.g. in struts-validator checking whether the received file size was acceptable
increasingly becomes a problem for uninterrupted server operation.

The concept of the future should be more proactive and optionally (configurable
in web.xml) apply the following more restrictive policies:
1) only accept fields with permitted names
2) only accept forms whose total length is declared with Content-Length (mozilla
already seems to do that for "Content-Type: multipart/form-data")
3) only accept fields whose length is declared with Content-Length (this allows
even more detailed user feedback)

This would allow to manage size matters from within the application:
For example, the application could make sure that only one logged in user at a
time can upload a 45 MB file while visitors not logged in cannot upload anything
beyond 10K - thus preventing unmanageable out-of-memory exceptions.

Especially policies 2 and 3 should be optional because the admin running the
server should be able to decide whether legacy browsers not providing such
information should be served or not.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org