About the Author

Chris Shiflett

Chris Shiflett is an author and speaker who leads the web application security practice at OmniTI.

My Top Two PHP Security Practices

Security is not a simple topic, but I think there is a great deal of value to be had in simplistic summaries of secure programming practices. Like an organization's mission statement, they provide a broad perspective that helps to keep you on track while you focus on the details. It is with this in mind that I have decided to promote my Top Two PHP Security Practices, expressed in four words:

  • Filter input
  • Escape output

These are practices that I've been promoting for years, but this is the first time that I've reduced them to such a simplistic list.

I believe that a failure to properly abide by these two practices accounts for a vast majority of all PHP application vulnerabilities. In fact, I am offering a challenge. I believe that at least four of the next five vulnerabilities announced on php|architect's PHP security mailing list will be due to a failure to properly abide by one (or both) of these practices. If I am wrong, I will donate one hundred dollars to the Open Web Application Security Project.

Update: Thanks to Adam's suggestion, I've reduced these practices to two words each.

About This Post

My Top Two PHP Security Practices was posted on Mon, 07 Feb 2005 at 02:42:19 GMT.

12 Comments

1. Rob Allen's GravatarRob Allen said:

I wouldn't bet against you!

Mon, 07 Feb 2005 at 11:57:49 GMT Link

2. Adam Trachtenberg's GravatarAdam Trachtenberg said:

Shorter is better. Filter input. Escape output.

Mon, 07 Feb 2005 at 18:55:19 GMT Link

3. Chris Shiflett's GravatarChris Shiflett said:

Even better. I'll modify it. :-)

Mon, 07 Feb 2005 at 19:21:35 GMT Link

4. Robert's GravatarRobert said:

Well, it occurs to me that all attacks come through some form of "input" -- typicall GET, PUT, or COOKIES for web applications. Some "input" is designed to get passed to another application (like MySQL) where, if not properly escaped, it can cause other unexpected behavior. I suppose this is a form of "output."

So, my question is: what other kind of security vulnerability exists besides one that can be exploited by input either directly or as that input later becomes output?

I'm guessing you get 5/5 using this logic. :)

Tue, 08 Feb 2005 at 05:44:34 GMT Link

5. Robert's GravatarRobert said:

s/PUT/POST -- and typicall should be "typically" -- sorry, it's late

Tue, 08 Feb 2005 at 05:45:33 GMT Link

6. Chris Shiflett's GravatarChris Shiflett said:

I can think of plenty of attacks and/or vulnerabilities that aren't directly the fault of filtering input or escaping output.

Cross-Site Request Forgeries: http://phpsec.org/projects/guide/2.html#2.4

Exposed Access Credentials: http://phpsec.org/projects/guide/3.html#3.1

Session Fixation: http://phpsec.org/projects/guide/4.html#4.1

Exposed Session Data: http://phpsec.org/projects/guide/5.html#5.1

Browsing the Filesystem: http://phpsec.org/projects/guide/5.html#5.2

Those are just from a quick glance at the PHP Security Guide (which still fails to address many topics - I plan to address this soon). Of these, only Cross-Site Request Forgeries and Session Fixation are truly application problems (rather than environment problems), but there are others.

I do think that a failure to filter input or escape output accounts for the vast majority of all PHP application vulnerabilities, and this is why I tried to summarize these important tasks like this. I don't expect to lose - I just want people to see that I'm serious.

Tue, 08 Feb 2005 at 06:03:30 GMT Link

7. Robert's GravatarRobert said:

Well, I certainly see you're serious and point well taken -- true we can't control everything that goes on between browser and server (like DNS for example) but the parts we can control -- between input and output -- need careful examination.

Wed, 09 Feb 2005 at 01:24:44 GMT Link

8. Pure-PHP's GravatarPure-PHP said:

I have the idea a "java-like" HttpRequest class, which look like this:

$id = $post->getInt("id");

$name = $post->getString("name);

More infos

http://www.pure-php.de/node/18

So we can avoid most of the security problemes.

Mon, 14 Mar 2005 at 20:16:59 GMT Link

9. Chris Shiflett's GravatarChris Shiflett said:

I "won" the challenge, even though the first vulnerability Marco posted after I blogged about this was a PostgreSQL vulnerability, and therefore not really related. :-)

Three of the next four he posted were all SQL injection vulnerabilities, and this is partially why some of my talks describe SQL injection and XSS as the two biggest concerns for PHP developers.

Tue, 15 Mar 2005 at 06:18:18 GMT Link

10. Hossein's GravatarHossein said:

Hello chris,

You said:

"Hi Hossein,

Escaping output is a generic way to describe the fact that you need to escape any data that leaves your application. An SQL query sent to a database is output, because it is leaving your application.

It doesn't matter what the purpose of the SQL query is. Even a SELECT query is output.

Regarding your question about filtering, I think it's best to perform your filtering as soon as you receive data from a third party."

And in your book:

"What is particularly surprising about this fact is that an SQL injection vulnerability requires two failures on the part of the developera failure to filter data as it enters the application (filter input), "

May you give me example about "filter input" that is related to SQL injection?

Wed, 17 Jan 2007 at 11:59:45 GMT Link

11. Chris Shiflett's GravatarChris Shiflett said:

Hi Hossein,

I have an article on SQL injection:

http://shiflett.org/articles/sql-injection

There is a section on input filtering that might be helpful.

Wed, 17 Jan 2007 at 15:40:57 GMT Link

12. llinear's Gravatarllinear said:

Input/output filtering is a subset of what academics call implementation vulnerabilities. The other class of vulnerability would be architectural.

An addition to the list of attacks and/or vulnerabilities that aren't directly the fault of filtering input or escaping output is the Timing Attack: crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

Fri, 26 Jan 2007 at 21:31:13 GMT Link

Post A Comment

Personal Details and Comment

Style Guide

Line breaks are converted to paragraphs. Also use:

  • <a href="" title="">text</a>1
  • <em>text</em>
  • <blockquote><p>text</p></blockquote>
  • <code>2  <?php  if ($foo) {      $foo = TRUE;  }  ?></code>
  1. Note: <code> can be used inline (e.g. in paragraphs) or in a block as shown. Include whitespace and newlines in blocks.

Please enter Chris (my first name) below. This is a primitive spam prevention technique, and I apologize for the inconvenience.

Preview and Submit

Upcoming Talks

PHP Appalachia

11 - 14 Oct 2008

At Big Bear Lodge, Gatlinburg, Tennessee.

php|works / PyWorks

12 - 14 Nov 2008

At Sheraton Gateway Hotel Atlanta Airport, Atlanta, Georgia.

New Comments

Chris Shiflett wrote:

Thanks, Brandon. I'm glad you liked the talk. Maybe some parts of it would be interesting to some...

Posted in ZendCon
Brandon Savage wrote:

Thanks for the great rundown. Your talk was exceptional. It changed the way I design. I won't be ...

Posted in ZendCon
Rico wrote:

I don't understand why anyone would use .inc as a PHP file extension. I have always found this cr...

Posted in Security Corner: Secure Design
David wrote:

Thanks for the writeup on "ZendCon" - it is a lot of fun to read for people that miss it for one ...

Posted in ZendCon
Chris Shiflett wrote:

Keith Casey wrote a summary as well: http://caseysoftware.com/blog/zendcon-2008-closing-notes

Posted in ZendCon

Browse Comments