If you??™re new to all of this, what??™s the big deal?
Historically, all external variables were automatically registered in the global
scope. That is, any incoming variable of the types COOKIE, ENVIRONMENT, GET, POST, and
SERVER were made available globally. Because they were available globally, they were
also globally modifiable. Although this might seem convenient to some people, it also
introduced a security deficiency because variables intended to be managed solely by
using a cookie could also potentially be modified via the URL. For example, suppose that
a session identifier uniquely identifying the user is communicated across pages via a
cookie. Nobody but that user should see the data that is ultimately mapped to the
user identified by that session identifier. A user could open the cookie, copy the session
identifier, and paste it onto the end of the URL, like this:
http://www.example.com/secretdata.php?sessionid=4x5bh5H793adK
The user could then e-mail this link to some other user. If there are no other security
restrictions in place (e.g., IP identification), this second user will be able to see the
otherwise confidential data. Disabling the register_globals directive prevents such
behavior from occurring. While these external variables remain in the global scope, each
must be referred to in conjunction with its type. For example, the sessionid variable in
the previous example would instead be referred to solely as the following:
$_COOKIE['sessionid']
Any attempt to modify this parameter using any other means (e.
Pages:
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124