About the Author

Chris Shiflett

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


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 Sun, 06 Feb 2005. If you liked it, follow me on Twitter or share:

13 comments

1.Rob Allen said:

I wouldn't bet against you!

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


2.Adam Trachtenberg said:

Shorter is better. Filter input. Escape output.

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


3.Chris Shiflett said:

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

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


4.Robert 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 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 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 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 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 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 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 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 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


13.Artem Nezvigin said:

I would also add "Don't Trust your Application". On larger projects you may spend months writing a single component of your overall application. When you're finished, this large component of your application becomes an entity in itself - DONT TRUST IT! Don't assume that just because the data is coming from your application, its safe.

I would preach: "don't trust any component other than the one you're working on"

Tue, 05 May 2009 at 15:58:30 GMT Link


Hello! What’s your name?

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