You now proceed to construct your query with, first, the invariable portion (we show here
only the resultant value of the $query variable):
only the resultant value of the $query variable):
SELECT * FROM wines WHERE variety = '
You then concatenate that with the value of the variable containing what the user entered
(here shown in bold type):
SELECT * FROM wines WHERE variety = 'lagrein' or 1=1;
And finally you add the closing quotation mark:
SELECT * FROM wines WHERE variety = 'lagrein' or 1=1;'
The resulting query is very different from what you had expected. In fact, your query now
consists of not one but rather two instructions, since the semicolon at the end of the user’s
entry closes the first instruction (to select records) and begins another one. In this case, the
second instruction, nothing more than a single quotation mark, is meaningless.
But the first instruction is not what you intended, either. When the user put a single quotation
mark into the middle of his entry, he ended the value of the desired variable, and introduced
another condition. So instead of retrieving just those records where the variety is “lagrein,” in
this case you are retrieving those records that meet either of two criteria, the first one yours and
the second one his: the variety has to be “lagrein” or 1 has to be 1. Since 1 is always 1, you are
therefore retrieving all of the records!
consists of not one but rather two instructions, since the semicolon at the end of the user’s
entry closes the first instruction (to select records) and begins another one. In this case, the
second instruction, nothing more than a single quotation mark, is meaningless.
But the first instruction is not what you intended, either. When the user put a single quotation
mark into the middle of his entry, he ended the value of the desired variable, and introduced
another condition. So instead of retrieving just those records where the variety is “lagrein,” in
this case you are retrieving those records that meet either of two criteria, the first one yours and
the second one his: the variety has to be “lagrein” or 1 has to be 1. Since 1 is always 1, you are
therefore retrieving all of the records!
You may object that you are going to be using double rather than single quotation marks
to delineate the user’s submitted variables. This slows the abuser down for only as long as it
takes for it to fail and for him to retry his exploit, using this time the double quotation mark that
permits it to succeed. (We remind you here that, as we discussed in Chapter 11, all error notification to the user should be disabled. If an error message were generated here, it would have
just helped the attacker by providing a specific explanation for why his attack failed.)
to delineate the user’s submitted variables. This slows the abuser down for only as long as it
takes for it to fail and for him to retry his exploit, using this time the double quotation mark that
permits it to succeed. (We remind you here that, as we discussed in Chapter 11, all error notification to the user should be disabled. If an error message were generated here, it would have
just helped the attacker by providing a specific explanation for why his attack failed.)
As a practical matter, for your user to see all of the records rather than just a selection of
them may not at first glance seem like such a big deal, but in actual fact it is; viewing all of the
records could very easily provide him with insight into the structure of the table, an insight that
could easily be turned to more nefarious purposes later. This is especially true if your database
contains not something apparently innocuous like wines, but rather, for example, a list of
employees with their annual salaries.
them may not at first glance seem like such a big deal, but in actual fact it is; viewing all of the
records could very easily provide him with insight into the structure of the table, an insight that
could easily be turned to more nefarious purposes later. This is especially true if your database
contains not something apparently innocuous like wines, but rather, for example, a list of
employees with their annual salaries.
And as a theoretical matter, this exploit is a very bad thing indeed. By injecting something
unexpected into your query, this user has succeeded in turning your intended database access
around to serve his own purposes. Your database is therefore now just as open to him as it is to
you.
unexpected into your query, this user has succeeded in turning your intended database access
around to serve his own purposes. Your database is therefore now just as open to him as it is to
you.
PHP and MySQL Injection
As we have mentioned previously, PHP, by design, does not do anything except what you tell it
to do. It is precisely that hands-off attitude that permits exploits such as the one we described
previously.
to do. It is precisely that hands-off attitude that permits exploits such as the one we described
previously.
We will assume that you will not knowingly or even accidentally construct a database query
that has destructive effects; the problem is with input from your users. Let’s therefore look now
in more detail at the various ways in which users might provide information to your scripts.
that has destructive effects; the problem is with input from your users. Let’s therefore look now
in more detail at the various ways in which users might provide information to your scripts.
Kinds of User Input
The ways in which users can influence the behavior of your scripts are more, and more complex, than they may appear at first glance.
The most obvious source of user input is of course a text input field in a form. With such a
field, you are deliberately soliciting a user’s input. Furthermore, you are providing the user
with a wide open field; there is no way that you can limit ahead of time what a user can type
(although you can limit its length, if you choose to). This is the reason why the overwhelming
source for injection exploits is the unguarded form field.
field, you are deliberately soliciting a user’s input. Furthermore, you are providing the user
with a wide open field; there is no way that you can limit ahead of time what a user can type
(although you can limit its length, if you choose to). This is the reason why the overwhelming
source for injection exploits is the unguarded form field.
But there are other sources as well, and a moment’s reflection on the technology behind
forms (the transmission of information via the POST method) should bring to mind another
common source for the transmission of information: the GET method. An observant user can
easily see when information is being passed to a script simply by looking at the URI displayed
in the browser’s navigation toolbar. Although such URIs are typically generated programmatically, there is nothing whatsoever stopping a malicious user from simply typing a URI with an
improper variable value into a browser, and thus potentially opening a database up for abuse.
forms (the transmission of information via the POST method) should bring to mind another
common source for the transmission of information: the GET method. An observant user can
easily see when information is being passed to a script simply by looking at the URI displayed
in the browser’s navigation toolbar. Although such URIs are typically generated programmatically, there is nothing whatsoever stopping a malicious user from simply typing a URI with an
improper variable value into a browser, and thus potentially opening a database up for abuse.
One common strategy to limit users’ input is to provide an option box rather than an input
box in a form. This control forces the user to choose from among a set of predetermined values,
and would seem to prevent the user from entering anything unexpected. But just as an attacker
might spoof a URI (that is, create an illegitimate URI that masquerades as an authentic one),
so might she create her own version of your form, with illegitimate rather than predetermined
safe choices in the option box. It’s extremely simple to do this; all she needs to do is view the
source and then cut-and-paste the form’s source code, which is right out in the open for her.
box in a form. This control forces the user to choose from among a set of predetermined values,
and would seem to prevent the user from entering anything unexpected. But just as an attacker
might spoof a URI (that is, create an illegitimate URI that masquerades as an authentic one),
so might she create her own version of your form, with illegitimate rather than predetermined
safe choices in the option box. It’s extremely simple to do this; all she needs to do is view the
source and then cut-and-paste the form’s source code, which is right out in the open for her.
After modifying the choices, she can submit the form, and her illegal instruction will be carried
in as if it were original.
So users have many different ways of attempting to inject malicious code into a script.
in as if it were original.
So users have many different ways of attempting to inject malicious code into a script.
Come back next week when we continue with our excerpt from Pro PHP Security!
reprinted with permission by Apress
