Postcards From My Life

Dear Reader,

I received an email today from a gentleman who is preparing to give a talk and needed to understand what is being done to make PHP more secure. He told me in his email that he understands that most of the problems these days were not problems with the language. He wanted to know, however, what the PHP community and core developers were doing to make it harder to write bad applications. Below is my response.

Hi XXX,

You are absolutely correct, the vast majority of the problems in PHP applications are due to the fact that the barrier to entry for programming PHP is very low. This means that anyone can quickly hammer together a form or website, with little or no training. The community as a whole is taking several steps.

Education

* Everywhere you turn, you will find tutorials on how to write PHP properly. This is not a Zend specific movement but we are involved. The mantra of “Filter Input, Escape Output” is being repeated everywhere. Additionally, we at Zend have been methodically reviewing all of our tutorials and sample code to make sure that any code we are presenting as sample code adheres to all “security best practices”. This is an ongoing effort, not a one-time effort as best practices change from time to time as new attack vectors are revealed.

* There are 3 major PHP centric conferences in the US every year, php|tek, php|works and ZendCon. Both php|works and ZendCon this year have talks specifically on how to write more secure code. Chris Shiflett, probably the most recognized authority on PHP security, is presenting his “Security 2.0″ at both conferences. Additionally, both conferences have other content on security and I can speak for ZendCon when I say that all sessions were vetted to make sure that the speakers and examples presented all support current best practices.

* In May of 2007, in response to Stefen Esser’s “Month of PHP Security Bugs” DevZone ran a daily “Month of Security Tips”. These are all still available and widely read according to my daily log analysis. Both of these efforts were designed to raise awareness of the problems that PHP developers face. In the case of “Month of PHP Bugs”, most of the bugs that Stefen announced were dealt with in the PHP 5.2.2 and PHP 4.4.7 releases on May 2nd.

Coding

* As new attack vectors are revealed that compromise a flaw in the Zend Engine, the Core PHP team moves quickly to resolve them. Many times the patch is forthcoming days after the vector is revealed however in some cases, it takes longer as a quick fix may solve one problem but introduce two more.

* As we’ve agreed though, the majority of attack vectors have little to do with the Zend Engine. The are of the nature of “Cross Site Scripting” (XSS) or “SQL Injection” attacks. In these cases, there is little the community can do beyond education.

You mentioned register_globals, that and safe_mode, allow_url_fopen are options in the PHP ini file that were early attempts to “make the language safer” and are now widely regarded as giving users a false sense of security. As the owner of two shared hosting services, I can tell you that by-in-large, most users do not understand the proper use of these options and simply think that if they are off, they are safe.

To avoid confusion like this in the future, the community is moving away from trying to make the language safe for new programmers and is concentrating on simply making the tools available to do the job right. This fits hand in hand with the education effort.

* Tools like ext/filter are now standard on PHP 5. This gives programmers an easy way to do things like filter out extraneous html and JavaScript from input, validate that an email address is of the proper format and other necessary tasks. This tool alone cannot make your site
secure but using it properly can greatly reduce your exposure to XSS and SQL injection attacks.

* Frameworks today help with a lot of this. Currently there are over 100 frameworks written in PHP, however, it boils down to 4-5 of them control about 80% of the market. symfony, CakePHP, Solar, CodeIgniter and of course, the Zend Framework. Selecting the proper framework and investing in the time it takes to climb the learning curve will help any developer become a better developer and write more secure applications. Because I work for Zend, I use the Zend Framework and am most familiar with it. In the Zend Framework, it is very easy to filter and validate all incoming input. Again, if you can prevent malicious users from injecting code into your application, you can prevent most attacks.

Until next time,
(l)(k)(bunny)

Related posts

• No related posts.

This entry was posted on Thursday, August 23rd, 2007 at 7:20 pm and is filed under PHP, Programming. You can follow any responses to this entry through the RSS 2.0 feed.Both comments and pings are currently closed.