php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #3517 HTTP_COOKIE_VARS, HTTP_POST_VARS, HTTP_GET_VARS open to manipulation
Submitted: 2000-02-17 10:56 UTC Modified: 2005-03-31 16:13 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: naklar at altavista dot net Assigned:
Status: Wont fix Package: Misbehaving function
PHP Version: 3.0.14 OS: Windows CGI version, probably al
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2000-02-17 10:56 UTC] naklar at altavista dot net
HTTP_COOKIE_VARS,HTTP_POST_VARS,HTTP_GET_VARS are useful to determine 
the origin of a global Variable. Unfortunately, a statement like this:  
www.domain.tld?HTTP_COOKIE_VARS=nothing 
destroys the array. This enables possible attacks and malfunctions 
against any session management, which relies on the evaluation 
of the array data.


Example (with error_reporting = 15)

1. "normal behaviour":
URL: http://test/_sessiontest/httpcookievars.php
<?php
SetCookie("testcookie", "identifier", 0); 
reset($HTTP_COOKIE_VARS);
while (list ( $k,$v)=each ($HTTP_COOKIE_VARS))
{echo "<br>$k = $v";}
?>
Cookie is set/was already set. Result is ok:  
  testcookie = identifier

2. "misbehaviour / attack":
URL: http://test/_sessiontest/httpcookievars.php?HTTP_COOKIE_VARS=nix

Cookie is set/was already set. Result is not ok:  

 Warning: Variable passed to reset() is not an array or object in 
 d:\www\test\_sessiontest\httpcookievars.php on line 4

 Warning: Variable passed to each() is not an array or object in 
 d:\www\test\_sessiontest\httpcookievars.php on line 5


The results can be reproduced.

Possible Solution:
The mentioned Arrays should be under any circumstances READ/ONLY to avoid such errors.

Thx. oK

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-02-17 20:11 UTC] joey at cvs dot php dot net
This seems to only be a concern if all you are doing for "session management" is testing /IF/ a variable is set, 
rather than using sessions the way that (AFAIK) they are meant to be used...ie, make sure that whatever
session vars are passed by user still exist, either in DB or filesystem, however you implemented your sess.
management.

There are times when I actually dig into the HTTP_POST_VARS for very good reasons, as do some others,
so making these read only is not, IMO, a good idea.

I am not denying that this /may/ be a security risk to some degree, but your bug report
A) Does not (IMO) give a valid example of /HOW/ this could be abused
B) Your suggested fix does not seem to be the best way around such issues.
 [2005-03-31 16:13 UTC] php-bugs at lists dot php dot net
We are sorry, but we do not support PHP 3 related problems anymore.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sat Jul 11 17:01:27 2020 UTC