About the Author

Chris Shiflett

Hi, I’m Chris: web craftsman, community leader, husband, father, and partner at Fictive Kin.

PHP Advent Calendar Day 15

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:

  • Use mysql_real_escape_string() when you're sending data to a MySQL database.

  • Use htmlentities() when you're outputting data to a web page.

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 php.net 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.

About this post

PHP Advent Calendar Day 15 was posted on Sat, 15 Dec 2007. If you liked it, follow me on Twitter or share:


1.Jorrit Schippers said:

Nowadays I use htmlspecialchars(), because entities such as &euml; are not allowed in XHTML, and if you have your character encodings right, ë should work just as well as &euml;

Sun, 16 Dec 2007 at 11:09:56 GMT Link

2.Lars Gunther said:

Could be better:

It is time to teach prepared statements. That is even better than mysql_real_escape_string(). I teach PHP to newbies as a job. Nowadays I start with PDO, and make only mention the mysql interface.

I good:

Otherwise I agree, and I think it's important to explain the principle, as people are confusing filtering with escaping all the time.

Sun, 16 Dec 2007 at 11:12:04 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.