Bug #71599 [Dup]: trans sid handling rework broke interaction with cookies

Edit report at https://bugs.php.net/bug.php?id=71599&edit=1 ID: 71599 User updated by: phpbug at wisl dot de Reported by: phpbug at wisl dot de Summary: trans sid handling rework broke interaction with cookies Status: Duplicate Type: Bug Package: Session related Operating System: All PHP Version: 7.0.3 Assigned To: yohgaki Block user comment: N Private report: N New Comment: This is not a duplicate of #71683. The crash that I also noted might be a duplicate of #71683, but that got fixed as bug #71754. The logic wrt. the transparent session id when a cookie is available and that multiple calls to session_regenerate_id() add multiple PHPSESSID parameters is broken in PHP7 compared to PHP5.X and this can't be fixed with the crash fix from #71683 or #71754. Please reopen this bug. Previous Comments: ------------------------------------------------------------------------ [2016-03-11 01:33:11] yohgaki@php.net The cause is jit global change in PHP7. Related to bug #71683 ------------------------------------------------------------------------ [2016-03-10 18:12:43] cmb@php.net Yasuo, could you please have a look at this issue? ------------------------------------------------------------------------ [2016-03-10 10:11:30] phpbug at wisl dot de Crash has been fixed as Bug #71754: https://bugs.php.net/bug.php?id=71754 But the problem that the transparent session id rework is broken still persists. session_regenerate_id() for example is also broken. My application does a session_regenerate_id() when a new session is started to prevent session fixation attacks. Because of that on the first request all URLs had two PHPSESSID parameter added. The effect and that this is only broken in PHP7 can be seen with the following test script: bugtest3.php: <?php ini_set("session.use_only_cookies","0"); ini_set("session.use_trans_sid","1"); session_start(); for($i=0;$i<$_REQUEST["count"];$i++) session_regenerate_id(); ?> <a href="bugtest3.php?count=0">0</a></br> <a href="bugtest3.php?count=1">1</a></br> <a href="bugtest3.php?count=2">2</a></br> <a href="bugtest3.php?count=3">3</a></br> Using the URL bugtest3.php?count=3 under PHP 5.5 without having a cookie set results in hrefs like "bugtest3.php?count=3&PHPSESSID=f94bqpvtgksdiro232qolclut6". That is the correct and expected behavior. Under PHP 7.0.4 the URLs look like this: "bugtest3.php?count=3&PHPSESSID=pgvvh2d39jpr4vnubnq2r2m800&PHPSESSID=umpctfqdp4q0av74l6mtflmqp3&PHPSESSID=a94c7n4694n2rrkqc2tlnlt1k3&PHPSESSID=ek4m6ikt29po9oh6045m1fpke2" Each call to session_regenerate_id() seems to add another rewriter and an additional PHPSESSID parameter. Could somebody please look into this? ------------------------------------------------------------------------ [2016-02-15 16:09:51] phpbug at wisl dot de The segfault seems to be something different. It can only be seen in the CGI version of php, but the script to reproduce is minimal: <?php ini_set("session.use_only_cookies","0"); session_start(); ?> After building php with more debug info, I got the following, better backtrace: Program received signal SIGSEGV, Segmentation fault. zend_hash_str_find (ht=0x0, str=str@entry=0xe1fb4e "REQUEST_URI", len=len@entry=11) at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/Zend/zend_hash.c:1959 1959 /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/Zend/zend_hash.c: No such file or directory. (gdb) bt #0 zend_hash_str_find (ht=0x0, str=str@entry=0xe1fb4e "REQUEST_URI", len=len@entry=11) at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/Zend/zend_hash.c:1959 #1 0x00000000006975a0 in php_session_start () at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/ext/session/session.c:1613 #2 0x0000000000698d25 in zif_session_start (execute_data=<optimized out>, return_value=0x7ffff0612090) at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/ext/session/session.c:2312 #3 0x00000000008feeee in ZEND_DO_ICALL_SPEC_HANDLER () at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/Zend/zend_vm_execute.h:586 #4 0x00000000008ee59b in execute_ex (ex=<optimized out>) at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/Zend/zend_vm_execute.h:414 #5 0x0000000000971826 in zend_execute (op_array=<optimized out>, return_value=<optimized out>) at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/Zend/zend_vm_execute.h:458 #6 0x000000000089f901 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/Zend/zend.c:1427 #7 0x000000000081bb18 in php_execute_script (primary_file=primary_file@entry=0x7fffffffd310) at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/main/main.c:2484 #8 0x000000000048daa0 in main (argc=<optimized out>, argv=<optimized out>) at /var/tmp/portage/dev-lang/php-7.0.3/work/sapis-build/cgi/sapi/cgi/cgi_main.c:2453 session.c:1613+1614 is: if (PS(define_sid) && !PS(id) && (data = zend_hash_str_find(Z_ARRVAL(PG(http_globals)[TRACK_VARS_SERVER]), "REQUEST_URI", sizeof("REQUEST_URI") - 1)) && The commit linked above removed a "!Z_ISUNDEF(PG(http_globals)[TRACK_VARS_SERVER])", that might explain this additional segfault, but this breakage is unrelated to the fact that use_trans_sid can no longer be used as a simple fallback for users that forbid cookies, as it now no longer skips the url rewriting, when a cookie is available. ------------------------------------------------------------------------ [2016-02-15 15:33:16] phpbug at wisl dot de Description: ------------ I am using session.use_trans_sid=1 as a transparent fallback for users who have cookies disabled. By setting both use_trans_sid and use_cookies until PHP7 the cookie users would silently be upgraded to using cookies, while users without cookies could still use the session related function due to PHPSESSID that was written automatically into the html. Cause seems to be this commit: https://github.com/php/php-src/commit/f248df900300c5b2201d4cf634d58d413399e2eb "Cleanup trans sid code. Behavior is unchanged." But the behavior is changed, because the new macro APPLY_TRANS_SID only looks for the ini settings use_trans_sid and use_only_cookies, but the code wrt. cookies like lines 540+541 was removed. Test script: --------------- <?php ini_set("session.use_cookies","1"); ini_set("session.use_only_cookies","0"); ini_set("session.use_trans_sid","1"); session_start(); ?> <a href="bugtest.php">Follow Me</a> Expected result: ---------------- On first call to the supplied test script (wenn saved as bugtest.php) the use_trans_sid feature will insert an additional parameter PHPSESSID into the <a href>, but because of use_cookies the script will also send an Set-Cookie-Header. After clicking the link, the same page will reopen again. But if cookies are allowed in the browser, the <a href> will now no longer contain a PHPSESSID parameter. After clicking the link, the <a href> should only still contain a PHPSESSID parameter, if there was no cookie set. This behavior works as expected as of PHP 5.6.18. Actual result: -------------- Under PHP7 (tested with 7.0.2 and 7.0.3) it will: * no longer send a Set-Cookie Header, despite use_cookies=1 and use_only_cookies=0 * will still rewrite the <a href> even if a cookies is already set While testing I tried to call the script under PHP7 without any PHPSESSID parameter or cookie and it even segfaulted: (gdb) run /srv/www/htdocs/bugtest.php Starting program: /usr/bin/php-cgi7.0 /srv/www/htdocs/bugtest.php [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00000000008b6507 in zend_hash_str_find () (gdb) bt #0 0x00000000008b6507 in zend_hash_str_find () #1 0x00000000006975a0 in php_session_start () #2 0x0000000000698d25 in zif_session_start () #3 0x00000000008feeee in ZEND_DO_ICALL_SPEC_HANDLER () #4 0x00000000008ee59b in execute_ex () #5 0x0000000000971826 in zend_execute () #6 0x000000000089f901 in zend_execute_scripts () #7 0x000000000081bb18 in php_execute_script () #8 0x000000000048daa0 in main () I will try to add more details for the segfault later... ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=71599&edit=1