php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #16052 Some predefined variables allow GET overwrite
Submitted: 2002-03-13 17:52 UTC Modified: 2002-08-14 19:16 UTC
From: rlm at pricegrabber dot com Assigned:
Status: Not a bug Package: Apache related
PHP Version: 4.1.2 OS: RH 7.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: rlm at pricegrabber dot com
New email:
PHP Version: OS:

 

 [2002-03-13 17:52 UTC] rlm at pricegrabber dot com 
It is possible to overwrite some predefined variables using GET URI variables (also, I would imagine, POST vars, but it's harder to test for those).  Consider the following as foo.php:

<?
$varlist = array('DOCUMENT_ROOT',
                                 'GATEWAY_INTERFACE',
                                 'HTTP_ACCEPT',
                                 'HTTP_ACCEPT_CHARSET',
                                 'HTTP_ACCEPT_ENCODING',
                                 'HTTP_ACCEPT_LANGUAGE',
                                 'HTTP_CONNECTION',
                                 'HTTP_COOKIE_VARS',
                                 'HTTP_ENV_VARS',
                                 'HTTP_GET_VARS',
                                 'HTTP_HOST',
                                 'HTTP_POST_FILES',
                                 'HTTP_POST_VARS',
                                 'HTTP_REFERER',
                                 'HTTP_SERVER_VARS',
                                 'HTTP_USER_AGENT',
                                 'PATH_TRANSLATED',
                                 'PHP_SELF',
                                 'QUERY_STRING',
                                 'REMOTE_ADDR',
                                 'REMOTE_PORT',
                                 'REQUEST_METHOD',
                                 'REQUEST_URI',
                                 'SCRIPT_FILENAME',
                                 'SERVER_ADMIN',
                                 'SERVER_NAME',
                                 'SERVER_PORT',
                                 'SERVER_PROTOCOL',
                                 'SERVER_SIGNATURE',
                                 'SERVER_SOFTWARE');

foreach ($varlist as $i)
        print "$i = '".${$i}."'<br>\n";
?>

=============

If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get "blarg" for either of those variables, rather than the value that should have been there from Apache and/or PHP.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-03-13 18:27 UTC] daniel@php.net 
read the manual on "variables_order"
 [2002-03-13 18:47 UTC] rlm at pricegrabber dot com 
Been there, done that. So, why don't any of the other variables from purportedly the same source (s/b "S", yes?) change when I request this on the command line?  The point is that either (a) the docs are broken here and the two variables in question aren't from the server, or (b) the EGPCS processing is broken, take your pick.
 [2002-03-13 18:56 UTC] rlm at pricegrabber dot com 
Incidentally, our variables_order flag is set to "GPCS".
 [2002-03-14 02:08 UTC] daniel@php.net 
are you sure? HTTP_* variables are environment variables. the variables_order is normally set to EGCPS (if not, change it) where "S" is not "Server Variables" but "SESSION Variables". this behaviour thus looks intentional - first HTTP_ACCEPT_CHARSET is set by the environment, then you overwrite it with a GET.
 [2002-03-14 02:10 UTC] daniel@php.net 
sorry, it's EGPCS by default.
 [2002-03-14 02:41 UTC] rlm at pricegrabber dot com 
Funny, the docs say the "S" stands for "Server" variables:

http://www.php.net/manual/en/configuration.php#ini.register-globals

Furthermore, it doesn't make any comment whatsoever as to the nature of the HTTP_* variables, though the predefined variables page claims some are Apache, and some are environment.

http://www.php.net/manual/en/language.variables.predefined.php

In this instance, it says HTTP_ACCEPT_CHARSET and HTTP_REFERER are both Apache (presumably, "S"erver, yes?) variables.  So are you saying this is a documentation bug?
 [2002-03-14 05:17 UTC] daniel@php.net 
No, it was my fault. I thought, session variables were primarily available in $_SESSION, then written to the global context with "variables order".
 [2002-08-14 19:16 UTC] iliaa@php.net 
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat May 18 19:01:30 2024 UTC