11

Security
Terms You’ll Need to Understand
n Data filtering
n register_globals
n SQL injection
n Command injection
n Cross-site scripting (XSS)
n Shared hosting
n safe_mode
n open_basedir

Techniques You’ll Need to Master

n Validating client data
n Understanding the register_globals directive
n Escaping data used in SQL statements
n Escaping data used in shell commands
n Preventing cross-site scripting attacks
n Understanding the safe_mode directive
n Understanding the open_basedir directive
178 Chapter 11 Security
Data Filtering
Data filtering, the process of validating data and filtering out that which is invalid, is
arguably the cornerstone of Web application security.The basic premise is quite simple:
Never trust foreign data, especially data from the client.
There are two fundamentally different approaches to data filtering: the whitelist
approach and the blacklist approach.With a whitelist approach, you assume data to be
invalid unless it is proven otherwise (by meeting certain requirements of validity).With a
blacklist approach, you assume data to be valid unless proven otherwise. Of course, the
whitelist approach is stricter, and therefore more secure.
More pertinent than the principles of data filtering are the applications of it, many of
which are covered in the following sections.
Register Globals
In PHP 4.2.0, the default value of the register_globals directive changed from
On to Off. PHP professionals are now expected to write code that does not rely on
register_globals.
When enabled, register_globals imports data from several different sources into
the global namespace. Of particular interest to most developers is that the data from
$_POST, $_GET, and $_COOKIE is available in regular global variables. For example, if a
POST request contains a variable named foo, not only is $_POST[‘foo’] created, but
$foo is also created.
Although this behavior is simple and well documented, it carries serious implications
with regard to data filtering.Whereas it is quite easy to determine that $_POST[‘foo’] is
something that needs to be validated prior to use, the origin of $foo is less clear when
register_globals is enabled. In addition, if variables are not properly initialized, it is
possible that you might use a variable sent from the client when you intend to be using
a variable that you create yourself. A common example of this mistake is as follows:
if (authorized())
{
$admin = true;
}
/* Later... */
if ($admin)
{
/* Sensitive activity */
}
Because $admin is not properly initialized, a user can arbitrarily set its value by leveraging
the behavior of register_globals. For example, the user can call the page with
SQL Injection 179
?admin=1 appended to the URL.This will cause $admin to be set to 1 at the beginning
of the script. An important point is that a user has no control beyond the start of the
script because a user can only manipulate the HTTP request. Once PHP begins execution,
the request has been received, and a user can do nothing more to affect the pending
response.This is why initializing your variables (and thereby overwriting any
user-injected values) is such a good practice.
Of course, with proper programming practices, register_globals does not pose a
significant risk. However, having register_globals enabled makes the magnitude of a
mistake much greater, and it also makes it more difficult to identify foreign data.
The following guidelines are recommended, regardless of whether register_globals
is enabled:
nAlways initialize variables
nDevelop with error_reporting set to E_ALL
nFilter all foreign data
SQL Injection
When querying a database, you will likely need to use foreign data in the construction
of your SQL statement. For example, when storing data, you might be using values that
the user supplies in an HTML form.When retrieving data, you might be using the user’s
username or some other client-supplied unique identifier as your primary key.
Regardless of the reason, using foreign data in the construction of an SQL statement is
something that poses a significant security risk.This cannot be avoided in most cases, but
there are some best practices that can help mitigate the risk.
The first step, of course, is to properly filter the data, as just discussed. Most SQL
injection vulnerabilities are a result of poor, or absent, data filtering. It is unlikely that
valid data is going to pose a serious security risk.
With valid data, the only remaining concern is that you escape the data.This includes
making sure that characters in the data aren’t misinterpreted as being part of the SQL
construct. If single quotes are properly escaped, this risk can be mitigated by always
enclosing the data in single quotes within your SQL statement. For example,
$sql = “insert into foo values (‘$bar’)”;
As long as $bar does not contain any unescaped single quotes, it cannot interfere with
the construction of the SQL statement. Of course, there are other characters worth
escaping, and depending on which database you use, PHP might have functions
specifically designed for this task. For example, MySQL users can rely on
mysql_escape_string() to do the escaping.
With some databases, certain data types (notably integers) cannot be enclosed in single
quotes, but the data filtering for this type of data can be much stricter so that the
other safeguards are less important.
180 Chapter 11 Security
Command Injection
Another dangerous activity is executing shell commands whereby the user has supplied a
part of the command. Mitigating this risk is very similar to mitigating the risk of SQL
injection, although there are some specific PHP functions that you should learn.
With properly filtered data, there are only two potential problems that you might
encounter regarding shell commands:
1. There might be metacharacters that can be used to execute arbitrary commands.
2. If the data being used to construct a command is intended to be a single argument,
there might be characters within the data that cause it to be interpreted as
multiple arguments instead.
These problems are solved with escapeshellcmd() and escapeshellarg(), respectively.
Data passed through escapeshellcmd() will be escaped such that it no longer poses a
risk of arbitrary shell command execution. Data passed through escapeshellarg() can
safely be used as a single argument.
Cross-Site Scripting
One of the most frequent vulnerabilities in modern PHP applications is cross-site scripting
(XSS). As with most security concerns, proper data filtering can practically eliminate
the risk of cross-site scripting. However, in this case, the real risk is when foreign data is
used in your output and thereby potentially displayed to other users.This is fairly typical
for applications such as Webmail, forums, wikis, and even 404 handlers.
The best defense of cross-site scripting is to use functions such as
htmlspecialchars() or htmlentities() on data prior to displaying it. Of these two
functions, htmlentities() is better for this purpose because it is more inclusive in
terms of what entities it encodes.
This is a blacklist approach, but because there are a finite number of welldocumented
characters that have a special meaning within HTML, it is actually a pretty
strong approach in this case. Of course, it is still best to be strict in your data filtering. If
you are expecting a person’s first name, should valid JavaScript make it through your data
filtering? Hopefully you agree that this is not desirable.
Other functions such a strip_tags() (that attempts to remove all valid HTML and
PHP) can also help in preventing cross-site scripting vulnerabilities, but this is an example
of a somewhat weaker blacklist approach than what htmlentities() provides.
Shared Hosting
A common dilemma among PHP developers is achieving a satisfactory level of security
on a shared host.There has been some effort to resolve some of the shared hosting security
concerns, but none of these can help a shared host reach the level of security that
you can achieve on a dedicated host.
Exam Prep Questions 181
Two particular attempts to address this problem are the safe_mode and open_basedir
directives.The safe_mode directive effectively limits the files that a PHP script can open
to those with the same ownership as the PHP script itself.This can help to prevent people
from casually browsing the entire filesystem using a specially crafted PHP script, but
it unfortunately cannot address situations in which other languages are used to achieve
the same.
The open_basedir directive is similar—except that instead of relying on file permissions,
it restricts the files that PHP can open to those within a certain directory.Thus,
PHP cannot be used to open files outside of the directory specified by open_basedir.
One somewhat tricky characteristic of open_basedir is that you can use partial names
to match more than one directory. For example, a value of /tmp/foo will match both
/tmp/foo and /tmp/foobar. If you want to restrict access to only /tmp/foo, you can use
a trailing slash so that open_basedir is set to /tmp/foo/.
Both of these directives require administrative access, of course; otherwise, a developer
could simply override these settings.
Exam Prep Questions
1. Which of the following data filtering methods can be described as a whitelist
approach?
A. Make sure that a username does not contain backticks or angled brackets.
B. Only allow alphanumerics and underscores in a username.
C. Pass all incoming data through strip_tags().
D. Use htmlentities() to escape potentially malicious characters.
Answer B is correct. Answer A is incorrect because this assumes that any username
without backticks or angled brackets is valid. Answer C is incorrect because this
only removes HTML and PHP tags, assuming everything else to be valid. Answer
D is incorrect because htmlentities() only encodes HTML entities and is not
intended to filter data at all.
2. With register_globals enabled, which of the following practices is particularly
important?
A. Initialize all variables.
B. Filter all foreign data.
C. Escape all data used in SQL statements.
D. Escape all data prior to output.
Answer A is correct. Answers B, C, and D are incorrect because these practices are
not dependent on whether register_globals is enabled.
182 Chapter 11 Security
3. What are the two most important practices to mitigate the risk of an SQL injection
vulnerability?
A. Disabling register_globals and enabling safe_mode.
B. Enabling safe_mode and filtering any data used in the construction of the
SQL statement.
C. Filtering and escaping any data used in the construction of the SQL statement.
D. Disabling register_globals and escaping any data used in the construction
of the SQL statement.
Answer C is correct.With properly filtered data, escaping any metacharacters that
remain can mitigate the remaining risks. Answers A, B, and D are incorrect because
register_globals does not directly affect the risk of SQL injection, and
safe_mode is unrelated.
4. If $foo is anticipated to be a string, what modification made to the following
query will mitigate the risk of an SQL injection vulnerability?
$sql = “insert into mytable values ($foo)”;
A. Specify the column name in the SQL statement.
B. Remove the parentheses surrounding $foo.
C. Replace the parentheses surrounding $foo with single quotes.
D. Add single quotes around $foo.
Answer D is correct. Answer A is incorrect because specifying the column name
does not affect the behavior of the SQL statement. Answers B and C are incorrect
because the parentheses are required.
5. What is the purpose of the escapeshellcmd() function?
A. To prepare data so that it can be used as a single argument in a shell command.
B. To remove malicious characters.
C. To escape metacharacters, so that they can’t be used to execute arbitrary
commands.
D. To prevent cross-site scripting attacks.
Answer C is correct. Answer A is incorrect because escapeshellcmd() does not
attempt to solve this problem. Answer B is incorrect because escapeshellcmd()
does not actually remove characters. Answer D is incorrect because escaping data
to protect against cross-site scripting is much different than escaping data to be
used in a shell command.
Exam Prep Questions 183
6. What is the purpose of the escapeshellarg() function?
A. To prepare data so that it can be used as a single argument in a shell command.
B. To remove malicious characters.
C. To escape metacharacters, so that they can’t be used to execute arbitrary
commands.
D To remove arguments from a shell command.
Answer A is correct. Answers B and D are incorrect because escapeshellarg()
does not remove characters. Answer C is incorrect because escapeshellarg()
does not attempt to solve this problem.
7. When is cross-site scripting a heightened risk?
A. When storing data submitted by the user.
B. When displaying foreign data.
C. When executing a shell command.
D. When opening a remote URL.
Answer B is correct.When displaying foreign data that is not properly escaped, you
can inadvertently expose your users to significant risk. Answer A is incorrect
because storing data poses no immediate threat, even though this might result in a
cross-site scripting vulnerability later. Answers C and D are incorrect because these
activities are unrelated.
8. Which of the following functions can be used to escape data such that it can be
displayed without altering the appearance of the original data?
A. htmlspecialchars()
B. addslashes()
C. escapeshellargs()
D. urlencode()
Answer A is correct because htmlspecialchars() will convert special characters
to HTML entities that will display correctly in any Web client. Answer B is incorrect
because addslashes() only escapes single quotes. Answer C is incorrect
because escapeshellargs() is only helpful when dealing with shell command
arguments. Answer D is incorrect because URL encoding is not interpreted by
Web clients except in the context of URLs.
184 Chapter 11 Security
9. What is the purpose of the open_basedir directive?
A. To indicate the directory that include() calls will use as a base.
B. To restrict file open access to a specific directory.
C. To set the working directory.
D. To allow additional file open access than that granted by safe_mode.
Answer B is correct. Answer A is incorrect because the behavior of include() is
unchanged. Answer C is incorrect because the working directory does not depend
on open_basedir. Answer D is incorrect because open_basedir is not affected by
whether safe_mode is enabled.
10. Which of the following activities can safe_mode help prevent?
A. Browsing the filesystem with a specially crafted PHP script.
B. Writing a Bash shell script to read session data.
C. Browsing the filesystem with a specially crafted Perl script.
D. Accessing another user’s database.
Answer A is correct because you’ll only be able to browse files that have the same
ownership as your PHP script. Answers B and C are incorrect because safe_mode
cannot affect scripts written in other languages. Answer D is incorrect because
safe_mode does not attempt to prevent database access.