About the Author

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

PHP Security Architecture

Fri, 27 Jan 2006 at 14:51:47 GMT
5 Comments
References

Andrew van der Stock wrote to let me know that he has posted a contextual overview of a security architecture for PHP. I think he clarifies many of the things he mentioned in his previous post, and he makes a statement that has been a guiding principle for me in my work on the Zend Framework:

Of course, it is possible to write insecure programs in any language if you try hard enough. What I want is the easiest way is also the safest way.

I'm really glad to hear Andrew make this statement, because I think it's a simple but important goal - make the easiest way the safest way. For example, I wrote recently about The addslashes() Versus mysql_real_escape_string() Debate. Which of those is easiest to type? Which is safest? When you want to output a username to the screen, is it easier to escape it with htmlentities() or just echo it and be done? We have some work to do.

One aspect of this discussion that has been heavily debated within the PHP community is whether PHP should provide a powerful and flexible foundation like C does, or whether it should behave more like a framework. For example, when the topic of XSS comes up, many people blame PHP for not doing something automatically such as removing specific characters or escaping. Others note that almost any PHP framework offers such protection, and they'd rather see PHP remain a foundation from which to build.

Not being a PHP core developer myself, I'm focusing my efforts on the framework side of things. However, I have high hopes for Andrew's influence, and it sounds like he's in touch with Rasmus:

I have a reply from Rasmus. Apparently, he saw Chris's blog and thus this rant, and replied.

Andrew's "Failure of Leadership" comment probably won't win him any brownie points, but at least he got some attention. :-)

About This Post

PHP Security Architecture was posted on Fri, 27 Jan 2006 at 14:51:47 GMT.

5 Comments

1. Richard Lynch said:

I don't think it's all that tricky to type mysql_real_escape_string.

If it IS that tricky, then you need to get a fancy IDE that can auto-complete for you.

I can see the argument for not doing htmlentities on a username, IF you know it was scrubbed on input and cannot possibly contain any characters that need escaping.

At that point, it would be like doing htmlentities on an integer or float, that you KNOW is a valid integer or float.

That data has an inherent structure and some intrinsic properties that make htmlentities moot.

For that matter, one could even consider running a validation suite on their data which included a test that htmlentities($username) === $username for all usernames.

While I can't think of any Black Hat utility that would take advantage of the difference, that doesn't mean there isn't one out there waiting to bite me, does it?

That said, it might be much easier to code a framework that treats all strings with htmlentities, whether they need it or not, and it wouldn't irk me if my strings with inherent properties known to not need htmlentities() were being passed through it. The performance hit can't be that high.

Fri, 27 Jan 2006 at 22:23:27 GMT Link

2. Pádraic Brady said:

addslashes() is easier to type, but when you get to mysql_real_escape_string() you hit a small bump. What if you're using Postgres, or MSSQL, or SQLite, or...

It then needs some structure to determine, and that traditionally been a framework's job.

As for the other, well defense in depth would suggest filtering can fail, in which case a second layer of protection, even if currently reduntant, has a valid use.

I really don't see PHP developing too far from its current state - be better to have a framework to manage such unwieldy tasks in the style of Ruby on Rails (which did an amazing job for Ruby - probably because of the small user base not creating multiple alternatives).
Sat, 28 Jan 2006 at 14:01:20 GMT Link

3. kristy oconnor said:

ok so someone hacked inot my email account and changed my password how do i get it back ?!
Tue, 31 Jan 2006 at 01:28:34 GMT Link

4. Seattle WA said:

PHP should try and make "the easiest way the safest way". However, this has to happen only when it makes sense or else the functionality and power of the language will be severely limited. For example, I think input filtering should reside within the framework and not as part of the language. PHP should make secure programming easy, but it shouldn't try to protect programmers from every single possible security issue.
Wed, 01 Feb 2006 at 01:40:39 GMT Link

5. Dotan Cohen said:

The easiest way will never be the safest way. Security and safety are complex subjects and are best handled on a case-by-case basis. If every php application had the same security model, then every php application would have the same security flaws. Let the programmer do the security, not the language.

Yet another reason to hire a professional programmer.
Fri, 03 Feb 2006 at 18:59:59 GMT Link

Amir wrote:: Hi chris! Please check this and guide me: http://forums.devnetwork.net/viewtopic.php?f=34&t=8...; Posted in
Nathan Bentley wrote:: Hi Chris, A great tutorial, which should help a lot of people! We implemented something simil...; Posted in
Daniel S wrote:: Just recently I sold my 1.gen Macbook(core duo version). And to be honest, I don't miss it for on...; Posted in Top X List of Mac OS X Annoyances
Buke Beyond wrote:: I agree it is ridiculous that php is doing this. I am using php for generating commands for othe...; Posted in PHP Stripping Newlines
Davis Ford wrote:: I agree, although I have a list of many more annoyances. However, rather than complain about the...; Posted in Top X List of Mac OS X Annoyances