>Number: 1916 >Category: mod_auth-any >Synopsis: wrong password for cgi script writes form data to log files >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Thu Mar 5 10:00:01 PST 1998 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.2.5 >Environment: IBM AIX level 4.1.4.0 / C Set ++ for AIX Compiler >Description: I am using secure cgi scripts (protected by an .htaccess file) to handle sensitive form data (user password change requests). The user must supply a valid userid and password to execute the script. If an incorrect password is supplied, the form data is incorrectly interpreted as being a URI, and is written to both the access log and error log files, and the form data, containing a requested new password, is visible to anyone with access to the log files.
Example access_log entry: www.client.com - userid [05/Mar/1998:11:48:48 -0500] "POST /cgi-bin/secure/chgpw.pl HTTP/1.0" 401 1667 www.client.com - - [05/Mar/1998:11:48:48 -0500] "newpw=newpassword" 400 - Example error_log entry: [Thu Mar 5 11:48:48 1998] access to /cgi-bin/secure/chgpw.pl failed for www.client.com, reason: user userid: password mismatch [Thu Mar 5 11:48:48 1998] Invalid URI in request newpw=newpassword Since the only copy of passwords I maintain are encrypted, this presents an unintended way for people to see user passwords. The second entry in each log should not be there, and presents a security exposure if a form contains sensitive data. >How-To-Repeat: You can use this HTML to generate the form data: <HTML><HEAD><TITLE>Test</TITLE></HEAD><BODY> <form action="http://www.server.com/cgi-bin/secure/chgpw.pl"; method="POST"> New Password <input name="newpw" type="PASSWORD" size=16 maxlength=16> <br><input type="SUBMIT" value="Change Password"> </form> </BODY></HTML> This needs to point to a script in a secure directory (protected by any typical .htaccess file). The actual script doesn't matter because it should not be executed for this example (you must supply an invalid password to your browser to cause the request to be rejected). You must also have log files enabled. >Fix: No. I could stop requesting sensitive data to be supplied via forms, but that is only a workaround >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
