Last modified: 2006-10-04 18:25:50 UTC
This CURL command: =========================================== curl --silent --include \ --cookie 'wikidb_session=../../../../../../../etc/passwd ; select user_name from user;'\ -F 'wpName'='XXX'\ -F 'wpPassword'='YYY'\ '192.168.0.64/wiki/index.php?title=Special:Userlogin&action=submitlogin&type=login&returnto=small' =========================================== (Or like this for the Wikipedia, where errors are being logged so there won't be anything in the HTML output): ========================================== curl --silent --include \ --cookie 'enwiki_session=../../../../../../../etc/passwd ; select user_name from user;'\ -F 'wpName'='XXX'\ -F 'wpPassword'='YYY'\ 'en.wikipedia.org/w/index.php?title=Special:Userlogin&action=submitlogin&type=login&returnto=small' =========================================== Gives output that includes these PHP warnings at the end (on a current SVN wiki with E_ALL enabled): =========================================== <br /> <b>Warning</b>: Unknown: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in <b>Unknown</b> on line <b>0</b><br /> <br /> <b>Warning</b>: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in <b>Unknown</b> on line <b>0</b><br /> =========================================== Online at http://nickj.org/MediaWiki as Parser51, althought actually a more accurate name would be non-parser51 ;-) Not sure if this can be fixed, but probably best to log it anyway.
I think this _may_ be fixed upstream in PHP by http://bugs.php.net/bug.php?id=38224 ; However I don't have PHP >= 5.1.5 installed to run this test against a wiki with E_ALL enabled, so can't be sure.
Haven't had any luck with the curl test here; lighttpd returns a 417 error.
Bugzilla ate some of the whitespace in the original test (specifically the spaces at the start of each line), maybe that stuffed it up? Here's the test with the whitespace hopefully okay. This was run against Apache, with PHP 5.1.2, and on a wiki where the cookie prefix is "wikidb", and where all E_ALL warnings are enabled : ================================ curl --silent --include --globoff \ --cookie 'wikidb_session=|90928345' \ -F 'wpName'='nickj' \ -F 'wpPassword'='<' \ -F 'wpRemember'='XXX' \ 'localhost/wiki/index.php?title=Special:Userlogin&action=submitlogin&type=login&returnto=' ================================ For me returns this output: ================================ HTTP/1.1 200 OK Date: Wed, 04 Oct 2006 00:09:16 GMT Server: Apache Set-Cookie: wikidb_session=| path=/ Content-language: en Vary: Accept-Encoding,User-Agent Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: private, must-revalidate, max-age=0 Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> [ ... snip page content ... ] </div> <!-- Served by bling in 0.211 secs. --></body></html> <br /> <b>Warning</b>: Unknown: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in <b>Unknown</b> on line <b>0</b><br /> <br /> <b>Warning</b>: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in <b>Unknown</b> on line <b>0</b><br /> ================================ Equivalent for the Wikipedia if you want to tail -f the apache error log and the see if it barfs there: ================================ curl --silent --include --globoff \ --cookie 'enwiki_session=|90928345' \ -F 'wpName'='XXX' \ -F 'wpPassword'='YYY' \ -F 'wpRemember'='XXX' \ 'en.wikipedia.org/w/index.php?title=Special:Userlogin&action=submitlogin&type=login&returnto=' ================================ However if neither of those tests works for you then it's probably just something specific to my system, and this bug should be closed as WORKSFORME.
I haven't been able to reproduce it either with 5.2.0RC4 or 5.1.2 under Apache. Still get the 417 responses under lighty. Going to go ahead and WORKSFORME it since the issue's allegedly fixed upstream.
