17.1     Programming secure PHP

This is NOT the latest copy of this book; click here for the latest version.

Up until version 4.1, PHP was designed to be easy to program, as opposed to being security-oriented. While this helped its popularity immensely in the short term, it also created a number of very badly written scripts, and gave a vast number of programmers a security-ignorant mindset.

The primary culprit was the automatic conversion by PHP of input data into script variables, a practice enabled by the php.ini setting "register_globals". With the release of PHP 4.1, this behaviour was deprecated - left enabled, but recommended against. With the release of PHP 4.2, this behaviour was disabled by default, breaking thousands of scripts the world over, but also forcing programmers to write more secure code - or at least making them explicitly state that they did not mind insecure code.

While making scripts break was a bad thing, almost everyone now agrees that it was a smart move, and one that was necessary for the language to continue growing. In this chapter, we will be looking at the register_globals debate, but also examining other ways to tighten up your PHP scripts.

It is important to remember that no matter how much work goes into securing PHP and Apache by their respective developer teams, at the end of the day a lot of the emphasis still lies with you - if your script is the weakest link in the chain, you can be sure that is where crackers will jump in.