Leading PHP Experts Join Forces to Establish the PHP Security Consortium
NEW YORK, NY - January 31, 2005 - An international group of PHP experts today announced the official launch of the PHP Security Consortium (PHPSC), a group whose mission is to promote secure programming practices within the PHP community through education and exposition while maintaining high ethical standards.
"As PHP has transitioned from personal projects to enterprise application development, the need to educate the community about secure programming practices has risen," said Chris Shiflett, the group's founder.
"PHP application security is a topic of growing importance," said Andi Gutmans, one of the group's charter members. "The launch of the PHP Security Consortium is a landmark event for the PHP community, and because most web development technologies face similar security concerns, we believe that developers using other solutions can also benefit from our efforts."About the PHP Security Consortium
Founded in January 2005, the PHP Security Consortium (PHPSC) is an international group of PHP experts dedicated to promoting secure programming practices within the PHP community. Members of the PHPSC seek to educate PHP developers about security through a variety of resources, including documentation, tools, and standards.
In addition to their educational efforts, the PHPSC engages in exploratory and experimental research in order to develop and promote standards of best practice for PHP application development.
About the Author
Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.
All posts for Jan 2005
Display posts by year and monthSkip this section and jump to the main content
I originally posted this as a comment on John's blog:
I must have missed the backlash this time, but I understand the scorn over Zend's marketing statements. In my opinion, the concern has more to do with the lack of credit given to Rasmus than anything else. When Rasmus is referenced as the creator of PHP, no one objects, nor do they seem to consider it to be hoarding credit from the many contributors to PHP.
Ask a mod_perl developer who created mod_perl, and they'll tell you Doug MacEachern. Ask them who the core mod_perl developers are now, and they'll name people like Stas Bekman and Geoff Young. Doug no longer contributes, but no one else can ever truly claim creation.
Andi and Zeev have made substantial contributions, and it's very likely that PHP would never have reached its current level of excellence without their early involvement. It is understandable for Zend to trumpet their founders' involvement with the language. However, I think there would be far fewer objections if Zend's marketing statements at least shared credit for the creation of the language. I personally think it makes sense for Zend to position itself as a company with key PHP creators and innovators as founders. We all know Andi and Zeev, and we know how substantial their involvement is. For the average company executive, however, they're lucky to have heard of PHP. Zend's marketing tries to make Andi and Zeev's roles sound as significant as they are.
I'm very glad to hear that they have intervened and will be toning down these statements. As for Zend calling itself "The PHP Company," I don't see a problem with that at all. It's no different than Xerox calling itself "The Document Company." It suggests a particular focus, and it's a marketing attempt to position itself as the only or paramount one of its kind. I could say I wrote "the book" on HTTP, and I think that's fine, even though there are others. :-)
Now there's even more reason to be using Apache-Test to test PHP applications:
From Geoff's blog:
today I added the ability to run client-side PHP scripts to Apache-Test. so, now you can have
all within the same t/ directory.
the perl script t/foo.t will run using perl, just like always. t/bar.php will run using the php command-line interpreter, while t/response/TestPHP/baz.php will run via PHP within the Apache runtime (through standard Apache-Test magic). and all are executed with a simple make test and tabulated on the command line like you would expect.
Geoff also provides an example t/foo.php:
diag('this is a php test');
is('php', 'perl', 'something php passed');
This is a really great testing framework for PHP that I hope keeps getting more and more attention.
I stumbled upon an interesting resource today - the XSS Cheatsheet. This is a really wonderful collection of XSS (cross-site scripting) test cases. If you don't know what XSS is, you might find the following resources helpful:
Christian has developed a script for filtering data specifically for XSS. He also has an example implementation where you can try it out for yourself - maybe someone with some free time can try entering all of the test cases to see if any of them expose a weakness.
I recently discovered a PDF that describes something called Session Riding. Having no idea what session riding is, I decided to read it. From the introduction:
In this paper we describe an issue that was raised in 2001 under the name of Cross-Site Request Forgeries (CSRF). It seems, though, that it has been neglected by the software development and Web Application Security community, as it is not part of recent Web Application Security discussions, nor is it mentioned in OWASP's Top Ten or the like.
I agree that CSRF is an important topic that is not given proper attention. I consider it to be one of the most dangerous web application attacks, especially after observing the results of my recent PHP security experiments.
We prefer to call this issue Session Riding which more figuratively illustrates what is going on.
To be clear, session riding is nothing more than a new name for Cross-Site Request Forgeries - an attack that has been discussed for four years and for which there exists four years of documentation. Of course, I suppose that you would have to get a new name adopted if you want your PDF on the topic to be a top Google result.
In short: with Session Riding it is possible to send commands to a Web application on behalf of the targeted user by just sending this user an email or tricking him into visiting a (not per se malicious but) specially crafted website.
This is actually completely backward. With CSRF, the victim unknowingly sends requests of the attacker's choosing to the target site. The attacker does not send "commands" (requests) on behalf of the victim. To be fair, the rest of the document demonstrates a correct understanding of CSRF, so this is apparently an honest mistake.
Most of this document is good. The main solution presented (Solution 1) is very similar to the solution I usually recommend, although it is a bit weaker and focuses more on the session risk. I believe that it offers adequate protection, else I would refute it. I'll let you read the document and come to your own conclusions about its merit as well as the merit of the other solutions presented.
What are your thoughts about renaming known security concerns? Are there special cases where it might be appropriate? I plan to continue to use the original term - CSRF is a more accurate description of the technique, and inconsistencies in naming aren't going to help people better understand it.
Complete details are available on the OSCON web site, but we're particularly interested in exploring how software development is moving to another level, and how developers and businesses are adjusting to new business models and architectures. We're looking for sessions, tutorials, and workshops proposals that appeal to developers, systems and network administrators, and their managers in the following areas:
Specific topics and tracks at OSCON 2005 include: Linux and other open source operating systems, Java, PHP, Python, Perl, Databases (including MySQL and PostgreSQL), Apache, XML, Applications, Ruby, and Security.
- All aspects of building applications, services, and systems that use the new capabilities of the open source platform
- Burning issues for Java, Mozilla, web apps, and beyond
- The commoditization of software: who and/or what can show us the money?
- Network-enabled collaboration
- Software customizability, including software as a service
- Law, licensing, politics, and how best to navigate other troubled waters
OSCON has always been a favorite conference of mine. I hope to see you there.
Following in the tradition of my 2003 Highlights, I'm recording my personal highlights of this past year. This is mostly for my own curiosity.
- My second book, the Zend PHP Certification Study Guide, was published
- Began writing Security Corner, my column for php|architect
- Began writing Guru Speak, my column for PHP Magazine
- Slashdotted for the second time
- Slashdotted for the third time
- Founded the PHP Security Consortium
- Created the PHP Security Workbook
- Created a PHP testing framework with Geoff Young
- Spoke at the O'Reilly Open Source Convention for the second time
- Spoke at ApacheCon for the second time
- Spoke at php|works, my first all-PHP conference
- Spoke at New York PHP for the first time
- Attended Foo Camp for the first time
- Attended YAPC for the first time
- Served on the Conference Selection Committee for the O'Reilly Open Source Convention
- Became a member of the Zend Advisory Board
- Helped create the Zend Certification Exam
- Became an instructor for Zend Online Training
- Blogged for a whole year
This list is a bit longer than last year's, and it certainly seemed like a busier year. Here's wishing everyone a happy 2005.
- Obsessed with the best.
- from Tobias van Schneider
- The American Formula
- from Fred Wilson
- Lessons from id Software co-founder John Romero
- from Jason Lotito
- Audio Of The Week: Andy and Flyover
- from Fred Wilson
- Announcing the First SHA-1 Collision
- Image-to-Image Demo
- Is Google Maps Trying to Be a Social Network?
- How to Run for Your Local School Board
- Straight Pole Curved Hole Optical Illusion Explanation
- GitHub’s Post-CSP Journey
- The Line of Death
- Across the USA by Train for Just $213
- The Legend of Zelda Design Docs