- Table of Contents
- General considerations
- Installed as CGI binary
- Installed as an Apache module
- Filesystem Security
- Database Security
- Error Reporting
- Using Register Globals
- User Submitted Data
- Hiding PHP
- Keeping Current
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.
|
