The PHP Security Consortium has officially launched. The following is the press release:
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.
The PHPSC web site (http://phpsec.org/) provides a
variety of security resources for PHP developers, including the
group's flagship project, the PHP Security
Guide.
"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.
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
t/foo.t
t/bar.php
t/response/TestPHP/baz.php
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:
<?php
require 'test-more.php';
plan(1);
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.
Want to go to the O'Reilly Open Source Convention 2005 for free? Go submit a proposal to give a talk. The conference runs from 01 Aug 2005 to 05 Aug 2005. Here is part of the CFP announcement:
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:
- 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
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.
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.
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.
del.icio.us
Digg
Reddit
Newsvine
