You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/12/04 10:52:35 UTC

DO NOT REPLY [Bug 25193] New: - Wrong Content-Length in POST could cause information leakage / misbehaviour

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=25193>.
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=25193

Wrong Content-Length in POST could cause information leakage / misbehaviour

           Summary: Wrong Content-Length in POST could cause information
                    leakage / misbehaviour
           Product: Tomcat 5
           Version: 5.0.16
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Tester
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: christian.hufgard@gmx.de


Hi, since we had some strange behaviour according to some parts of our software, 
we found something in Tomcat 4.1.18, 4.2.25 and 5.0.16 (guess so, also on lot of 
other versions..)
If a POST-request sends a wrong Content-length (too large), Tomcat does not send 
a HTTP 400 Code but continues to process the request. This is no really problem 
so far, since all parameters whith the POST-request are still read in a correct 
matter.

But if the client cuts the connection (presses the abort-button, goes offline, 
anyway..) Tomcat uses data from previous request to get the given 
content-length. (Seems the buffer is not cleared correctly). This could lead to 
some critical information leakage on client side, if paramters are bounced back 
to client (e.g. preview-functions in guestbooks, forums, ...) and can also some 
really strange behaviour if you use this information to generate and send an 
email. So content from other "mails" is taken and filled into a new mail.

Is there any workaround known?


Greetz

Christian

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