My Top Two PHP Security Practices

I wouldn't bet against you!

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

Shorter is better. Filter input. Escape output.

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

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

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

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

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

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

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

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

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