Specifications

Screening User Input
One of the principles of building a safe Web application is that you should never trust user
input. Always screen user data before putting it in a file or database or passing it through a sys-
tem execution command.
We’ve talked in several places throughout this book of techniques you can use to screen user
input. We’ll list these briefly here as a reference.
• The
addslashes() function should be used to filter user data before it is passed to a
database. This function will escape out characters which might be troublesome to a data-
base. You can use the stripslashes() function to return the data to its original form.
• Magic quotes. You can switch on the magic_quotes_gpc and magic_quotes_runtime
directives in your php.ini file. These directives will automatically add and strip slashes
for you. The magic_quotes_gpc will apply this formatting to incoming GET, POST, and
cookie variables, and the magic_quote_runtime will apply it to data going to and from
databases.
• The escapeshellcmd() function should be used when you are passing user data to a
system() or exec() call or to backticks. This will escape out any metacharacters that can
be used to force your system to run arbitrary commands entered by a malicious user.
• You can use the strip_tags() function to strip out HTML and PHP tags from a string.
This will avoid users planting malicious scripts in user data that you might echo back to
the browser.
• You can use the htmlspecialchars() function, which will convert characters to their
HTML entity equivalents. For example,
< will be converted to &lt;. This will convert
any script tags to harmless characters.
Providing Secure Storage
The three different types of stored data (HTML or PHP files, script related data, and MySQL
data) will often be stored in different areas of the same disk, but are shown separately in Figure
15.1. Each type of storage requires different precautions and will be examined separately.
The most dangerous type of data we store is executable content. On a Web site, this usually
means scripts. You need to be very careful that your file permissions are set correctly within
your Web hierarchy. By this we mean the directory tree starting from htdocs on an Apache
server or inetpub on an IIS server. Others need to have permission to read your scripts in order
to see their output, but they should not be able to write over or edit them.
The same proviso applies to directories within the Web hierarchy. Only we should be able to
write to these directories. Other users, including the user who the Web server runs as, should
E-commerce and Security
P
ART III
336
19 7842 CH15 3/6/01 3:40 PM Page 336