PHP Advent Calendar Day 15

15 Dec 2007

Today's entry, provided by Paul Reinheimer, is entitled Channels and Output.

Paul Reinheimer

Paul Reinheimer
Born in Vancouver, raised in Ontario, educated in Windsor, currently roaming the streets of beautiful Montreal. When not fighting off crazy Internet vixens, Paul pays his hosting and Internet bills by taking care of training for php|architect, launching his own projects like funcaday, and speaking at various conferences.
Montreal, Canada

When getting started with PHP programming, we memorize rules that those who came before us hand down, such as:

The rules might not initially make a lot of sense, but given time, we learn.

The primary reason we have such rules isn't that MySQL does a poor job of interpreting data and browsers are silly, but that we're sending data and commands (or data and metadata) through the same channel. A single stream of information carries information like and instructions like <title> tags. With a single stream that carries both the instructions and the data, the receiving system might misinterpret one for the other. This misinterpretation is the basis of problems like cross-site scripting and SQL injection.

To protect against these attacks, you have two choices. You can either separate the streams or escape the data to avoid confusion. When you use prepared statements with SQL, you are essentially separating the streams; the queries you send to the database are sent separately from the data, maintaining the necessary distinction.

Using separate channels is secure and convenient, but it isn't always an option. An alternative option is to escape the data. Escaping is deceptively simple; determine which characters might be misinterpreted as instructions (special characters), and escape those characters to preserve their original meaning. Native functions exist for most common contexts, such as htmlentities() for HTML and mysql_real_escape_string() for MySQL.

Be sure to take character encoding into account. For HTML, The Content-Type header should indicate the same character encoding as htmlentities(). For MySQL, mysql_real_escape_string() maintains this consistency for you.

The next time you're sending data to an external resource, see if it's possible to separate the channels. If not, refer to the external resource's documentation to determine which characters are treated in a special way, and escape your data accordingly.