PHP is a powerful language and the interpreter, whether
included in a web server as a module or executed as a
separate CGI binary, is able to
access files, execute commands and open network connections
on the server. These properties make anything run on a web
server insecure by default. PHP is designed specifically to
be a more secure language for writing CGI programs than Perl
or C, and with correct selection of compile-time and runtime
configuration options, and proper coding practices, it can
give you exactly the combination of freedom and security you
need.
As there are many different ways of utilizing PHP, there
are many configuration options controlling its behaviour. A
large selection of options guarantees you can use PHP for a
lot of purposes, but it also means there are combinations of
these options and server configurations that result in an
insecure setup.
The configuration flexibility of PHP is equally rivalled
by the code flexibility. PHP can be used to build complete
server applications, with all the power of a shell user, or
it can be used for simple server-side includes with little
risk in a tightly controlled environment. How you build that
environment, and how secure it is, is largely up to the PHP
developer.
This chapter starts with some general security advice,
explains the different configuration option combinations and
the situations they can be safely used, and describes
different considerations in coding for different levels of
security.
A completely secure system is a virtual impossibility,
so an approach often used in the security profession is one
of balancing risk and usability. If every variable
submitted by a user required two forms of biometric
validation (such as a retinal scan and a fingerprint), you
would have an extremely high level of accountability. It
would also take half an hour to fill out a fairly complex
form, which would tend to encourage users to find ways of
bypassing the security.
The best security is often inobtrusive enough to suit
the requirements without the user being prevented from
accomplishing their work, or over-burdening the code author
with excessive complexity. Indeed, some security attacks
are merely exploits of this kind of overly built security,
which tends to erode over time.
A phrase worth remembering: A system is only as good
as the weakest link in a chain. If all transactions are
heavily logged based on time, location, transaction type,
etc. but the user is only verified based on a single
cookie, the validity of tying the users to the transaction
log is severely weakened.
When testing, keep in mind that you will not be able
to test all possibilities for even the simplest of pages.
The input you may expect will be completely unrelated to
the input given by a disgruntled employee, a cracker with
months of time on their hands, or a housecat walking across
the keyboard. This is why it's best to look at the code
from a logical perspective, to discern where unexpected
data can be introduced, and then follow how it is modified,
reduced, or amplified.
The Internet is filled with people trying to make a
name for themselves by breaking your code, crashing your
site, posting inappropriate content, and otherwise making
your day interesting. It doesn't matter if you have a small
or large site, you are a target by simply being online, by
having a server that can be connected to. Many cracking
programs do not discern by size, they simply trawl massive
IP blocks looking for victims. Try not to become one.