httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request (fwd)
Date Wed, 12 Nov 1997 01:39:36 GMT
Hmm.  Apache isn't eating the request body when it returns a 401, causing
the below problem...

Wow, a MSIE problem that isn't caused by MS?  Amazing.

---------- Forwarded message ----------
Date: 12 Nov 1997 01:06:36 -0000
From: Ariel Glenn <ariel@columbia.edu>
To: apbugs@hyperreal.org
Subject: protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd,
garbage data in logs and (sometimes) garbled request


>Number:         1399
>Category:       protocol
>Synopsis:       MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd,
garbage data in logs and (sometimes) garbled request
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Tue Nov 11 17:10:01 PST 1997
>Last-Modified:
>Originator:     ariel@columbia.edu
>Organization:
apache
>Release:        1.2.4
>Environment:
SunOS  5.5.1 Generic_103640-08 sun4u sparc
(gcc)
>Description:
Using vanilla Apache 1.2.4, basic auth, set up .htaccess file for a 
cgi script that uses the POST method. create a form to point to that script
and pass some data. start up msie 4.0 under win95 (don't know
about other platforms), load the form, then submit the data. You are now looking
at the browser dialog box. check the access log for the server: a POST with no
user name, all ok. fill in the dialog box with a legitimate user and send it.
Now check the log: a pile of post data tacked on to the beginning of the
second POST request. No user name. but 200 ok... 

Here's an example of the POST that's sent:

POST /cgi-bin/test/ariel-test/test-cgi HTTP/1.1^M
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*^M
Referer: http://xxx.columbia.edu/~ariel/test/msie.html^M
Accept-Language: en-za^M
Content-Type: application/x-www-form-urlencoded^M
Accept-Encoding: gzip, deflate^M
User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95)^M
Host: xxx.columbia.edu^M
Content-Length: 359^M
Connection: Keep-Alive^M
^M
blot1=this+is+a+test+of+the+emergency+broadcasting+cookie+1&blot2=this+is+a+test+of+the+emergency+broadcasting+cookie+2&blot3=this+is+a+test+of+the+emergency+broadcasting+cookie+3&blot4=this+is+a+test+of+the+emergency+broadcasting+cookie+4&blot5=this+is+a+test+of+the+emergency+broadcasting+cookie+5&blot6=this+is+a+test+of+the+emergency+broadcasting+cookie+6

that's all one packet btw.
the server reply looks like:

HTTP/1.1 401 Authorization Required^M
Date: Tue, 11 Nov 1997 20:09:13 GMT^M
Server: Apache/1.2.4^M
WWW-Authenticate: Basic realm="msie 4.0 test"^M
Keep-Alive: timeout=15, max=100^M
Connection: Keep-Alive^M
Transfer-Encoding: chunked^M
Content-Type: text/html^M
^M
334^M
<head><title>Access Denied</title></head>
etc...

the second POST ought to look like the first one  but with the auth data. 
instead it has some duplicate headers. in any case:

POST /cgi-bin/test/ariel-test/test-cgi HTTP/1.1^M
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*^M
Referer: http://xxx.columbia.edu/~ariel/test/msie.html^M
Accept-Language: en-za^M
Content-Type: application/x-www-form-urlencoded^M
Accept-Encoding: gzip, deflate^M
User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95)^M
Host: xxx.columbia.edu^M
Content-Length: 359^M
Connection: Keep-Alive^M
Referer: http://xxx.columbia.edu/~ariel/test/msie.html^M
Accept-Language: en-za^M
Content-Type: application/x-www-form-urlencoded^M
Accept-Encoding: gzip, deflate^M
Authorization: Basic dGVzdDp0ZXN0^M
^M
blot1=this+is+a+test+of+the+emergency+broadcasting+cookie+1&blot2=this+is+a+test+of+the+emergency+broadcasting+cookie+2&blot3=this+is+a+test+of+the+emergency+broadcasting+cookie+3&blot4=this+is+a+test+of+the+emergency+broadcasting+cookie+4&blot5=this+is+a+test+of+the+emergency+broadcasting+cookie+5&blot6=this+is+a+test+of+the+emergency+broadcasting+cookie+6

that was also one packet.

the log entries:
dynamic-60-101.cc.columbia.edu - - [11/Nov/1997:15:53:32 -0500] "(POST /cgi-bin/test/ariel-test/test-cgi
HTTP/1.1)" 401 832 "(ref http://xxx.columbia.edu/~ariel/test/msie.html)"
dynamic-60-101.cc.columbia.edu - - [11/Nov/1997:15:53:40 -0500] "(blot1=this+is+a+test+of+the+emergency+broadcasting+cookie+1&blot2=this+is+a+test+of+the+emergency+broadcasting+cookie+2&blot3=this+is+a+test+of+the+emergency+broadcasting+cookie+3&blot4=this+is+a+test+of+the+emergency+broadcasting+cookie+4&blot5=this+is+a+test+of+the+emergency+broadcasting+cookie+5&blot6=this+is+a+test+of+the+emergency+broadcasting+cookie+6POST
/cgi-bin/test/ariel-test/test-cgi HTTP/1.1)" 200 1208 "(ref http://xxx.columbia.edu/~ariel/test/msie.html,
http://xxx.columbia.edu/~ariel/test/msie.html)"

and btw the server sends a good response; you get your script output, and the next 
time you access the script you aren't asked for login, which means that the 
auth did work, in spite of the log.

Occasionally we see the POST data getting tacked on to a request after the second 
POST; the script which originally brought the bug to my attention puts
out a page with inline images, and one of those GETs gets clobbered:
dialup-5-14.cc.columbia.edu - - [01/Nov/1997:12:04:18 -0500] "(POST /sec-cgi-bin/mad/ccs/madsearch
HTTP/1.1)" 401 362 "(ref https://www1.columbia.edu/sec/cu/ccs/recruiting/)"
dialup-5-14.cc.columbia.edu - cpw10 [01/Nov/1997:12:04:24 -0500] "(POST /sec-cgi-bin/mad/ccs/madsearch
HTTP/1.1)" 200 6864 "(ref https://www1.columbia.edu/sec/cu/ccs/recruiting/, https://www1.columbia.edu/sec/cu/ccs/recruiting/)"
dialup-5-14.cc.columbia.edu - - [01/Nov/1997:12:04:27 -0500] "(DATABASE=%2Fwwws%2Fdata%2Fcu%2Fccs%2Frecruiting%2Fdata%2Flogin&REPORT=%2Fwwws%2Fdata%2Fcu%2Fccs%2Frecruiting%2Freports%2Fmenu&ReportCompression=TrueGET
/sec/cu/ccs/graphics/slab2.jpg HTTP/1.1)" 501 340 "(ref https://www1.columbia.edu/sec-cgi-bin/mad/ccs/madsearch)"
and here the GET actually fails.


>How-To-Repeat:
I have a url but you won't have access to the logs. 
It only takes 5 minutes to set up your own test case though.
>Fix:

>Audit-Trail:
>Unformatted:


Mime
View raw message