..
// Show the secret if the user is authenticated
if($user_id) {
echo("Soylent Green is people!");
}
?>
With register_globals enabled, a malicious user can just access index.php?user_id=4
and the $user_id variable will be set to 4 from the query string. Since we presume the
authenticated( ) function returns false (as the user is not a legitimate user), the if
* Of course, these only represent vulnerable parts at the HTTPprotocol level. Later, we will see how vulnerabilities
can expose themselves at higher levels. Vulnerabilities at lower levels, such as TCPsession hijacking,
are usually not the developer??™s concern.
?? Yes, this is a misspelling, but it is too deeply entrenched in HTTPhistory to change now. Consider it a lesson
to protocol designers.
132 | Chapter 5: Security
statement is bypassed. When we get to the part of the code that contains the secret,
$user_id is still 4, and the secret is revealed even though the user was never successfully
authenticated.
This design leads to huge security problems because the user has the potential to
choose the value of any local variable that you do not explicitly set. Fortunately for
all, the register_globals option in PHP has been disabled for some time now by
default.
Form processing
We have a similar problem in Rails due to a compromise between security and brevity
of code. Rails supports mass assignment of form parameters to ActiveRecord
objects, so that form fields named person[first_name], person[last_name], and
person[email] can be used to build an ActiveRecord Person object with one line of
code:
person = Person.
Pages:
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205