Last night at the monthly NYPHP meeting, Nate Abele presented an introduction to CakePHP, a web application framework.
The New York subway wasn't cooperating with my schedule, and due to a problem affecting all uptown 4/5 trains, I was 30 minutes late to the talk. After speaking with Nate later, it sounds like I might have only missed a few minutes due to some technical difficulties he was having in the beginning. Here are some of my notes from the talk as well as the conversation we had over dinner and drinks later.
Cake has an array-based Active Record implementation. This is partly because Cake supports PHP 4 and tries to provide consistency between PHP 4 and PHP 5. For those wondering whether this cripples Cake's object support, Nate has this to say:
Cake brings PHP 5 OO constructs to PHP 4.
Cake supports scaffolding, although this wasn't demonstrated. Cake also includes a utility cleverly titled Bake. Not having any prior experience with Cake, it's not yet clear to me how these two features differ.
Cake's Ajax features rely on prototype. I bet David would appreciate this approach.
By request, Nate covered some of Cake's security features. As I've mentioned in the past, I think frameworks are a great way to help a lot of people implement safeguards and best practices that they might not have otherwise known about. For example, Django offers CSRF protection.
As you might expect, as long as you stick to the Cake way of generating output, it handles the escaping for you. It also sounds like it keeps up with character encoding consistency for you, but this is something I want to investigate further.
There is a feature to help prevent CSRF, although it isn't advertised as such. This is something else I want to investigate further.
I was especially pleased to learn that Cake is a very organized project with good IP practices. Contributors sign a CLA (Contributor License Agreement), and it's licensed under the MIT license.
CakePHP seems like a solid project with smart, passionate people leading the way. It is also quite popular:
From Ivan's blog:
It gives me great pleasure to announce that Thinking Stone and ModSecurity have been acquired! We will be joining forces with Breach Security, a company also focused on the web application firewall market.
For anyone unfamiliar with Ivan's work, he is the author of Apache Security (O'Reilly), the author of ModSecurity, a member of the Web Application Security Consortium, a founding principal of the PHP Security Consortium, and has made numerous other contributions to the web application security community.
Congrats, Ivan! Here's hoping this new acquisition helps you make ModSecurity even better.
For more information, check out the press release or the ModSecurity product page.
The latest interview on the Zend Developer Zone is with Theo Schlossnagle. Theo is probably best known among the PHP community as the founder of OmniTI (where I work), a company that Cal describes as "one of the premier PHP consulting companies in the world." Thanks, Cal. :-)
If you're interested in OmniTI's history or some of Theo's thoughts on scalability, it's worth reading. You might also be interested in Theo's new book, Scalable Internet Architectures.
In a previous blog post, I discussed the insecurity of cross-domain Ajax. In the comments, I referenced a cross-domain Ajax with Flash demonstration created by Julien Couvreur:
My initial observation leads me to believe that the target site has to allow these requests in a file called
You are correct: cross-site requests in Flash require an explicit opt-in from the server, using
crossdomain.xml. That file not only needs to be there, it also needs to identify which foreign domains are allowed to do cross-site requests (which is
'*', a wildcard, in most public web sites I've seen so far, like Yahoo, Amazon, etc.).
Yikes! Can you spot the problem? I certainly did. If a web site allows cross-domain Ajax requests initiated from anywhere, it is vulnerable to exactly the types of attacks I was describing. I immediately searched Google for some examples:
One of the first results was http://flickr.com/crossdomain.xml. (It no longer exists; keep reading.)
Oh no! Not Flickr! Because of this policy, I knew I could make any user of Flickr perform any action of my choosing. As a user of Flickr, I knew I could just as easily be the victim.
Luckily, Cal understood the vulnerability immediately, so Julien's exploit was unnecessary. However, we still collaborated to create an exploit that was similar to the Myspace worm. Users would automatically add you as a friend (and family, for good measure). Of course, the exploit worked, so the vulnerability was verified. Julien and I plan to write a paper on this particular attack in the near future, primarily to help others avoid making the same mistake.
Flickr has since isolated their API to a separate domain in order to resolve this particular problem. I haven't spent time researching the potential risks of this approach, specifically CSRF attacks that target an API, but at least the primary and obvious problem has been fixed. In addition, Cal was notified on the 11th of August and fixed the vulnerability on the 23rd. In less than two weeks, he had implemented a fix that required changing the endpoint of all API calls. I wish all vendors respected their customers this much. (Amazon, are you listening?)
If you have a public API and want to allow cross-domain Ajax requests with Flash, be sure to use a separate domain. If the user interface and API operate in the same domain, there's almost no limit to what an attacker can do.
Almost immediately after returning from my trip to Toronto, I headed to Brussels for EuroOSCON.
I missed EuroOSCON last year, because ZendCon was scheduled at the same time. This year produced a similar collision - the Microsoft Web Dev Technology Summit. (You can read Wez's summary for more information about that.) I was already scheduled to speak at EuroOSCON, so I had to decline.
As with most conferences, I had the pleasure of meeting a few new people and hanging out with old friends:
- Bre Pettis is the author of I Make Things, a cool blog about innovation, invention, and DIY. He was demonstrating his drawbot, also known as the center of attention during the conference. (Katrien has a photo of its creations.)
- Paul Hudson is the author of the free online PHP book that O'Reilly later published as PHP in a Nutshell.
- Dale Dougherty founded O'Reilly with Tim and is the editor and publisher of Make Magazine. PHP people might remember Dale as the guy who was instrumental in helping to support the PHPCommunity.org project, which is now in the process of being migrated to Ning.
- Nat Torkington is the coauthor of the Perl Cookbook and the Program Chair for OSCON (and EuroOSCON and Where 2.0 and ETel).
- Zak Greant is the Director of North America at eZ and also works with the Mozilla Foundation. Both endeavors are through his consulting company, Foo Associates.
I presented my PHP Security Audit HOWTO talk, and perhaps as a result of my severe lack of sleep, I didn't feel like I was able to engage the audience as much as I wanted. However, all of the feedback after the talk was very positive, so maybe everyone was just quietly listening and taking notes. :-)
I enjoyed EuroOSCON and my visit to Brussels, but I might focus on conferences in North America next year in an attempt to further reduce the number of conferences I attend. There's always OSCON, my perennial favorite.
I've been traveling non-stop since php|works, so I haven't had a chance to reflect on the conference, what I learned, who I met, and things like that. (Zak has been doing a good job of this lately, and I'd like to follow his lead.) I've probably forgotten more than I remember, but this is my recap.
I had the pleasure of meeting a number of people for the first time:
I presented The Truth about XSS and Agile PHP Testing, both of which went pretty well. I enjoy the cross-site scripting (XSS) talk, because it gives me a chance to highlight some new trends in web application security as well as discuss some of my current research. (If you're interested in keeping up with the latest developments, I highly recommend RSnake's blog.) I wasn't really in the mood to give my testing talk, so I spiced it up a bit by adding some information about security testing. I think everyone appreciated that, as it made the talk more fun.
After my talks, Cal Evans interviewed me for the Zend Developer Zone. His first question was how I became interested in computers, which is the same question Nat asked me for his Burn In series on O'Reilly Radar. I was too busy at the time to respond to Nat's request, so it was nice to get a chance to reminisce with Cal about my Commodore 64 and such. I'll let you know when the interview gets posted.
Other interesting highlights for me were the Zend PHP 5 Certification panel and the Great PHP Trivia Tournament. The latter was a trivia contest with questions like:
- Spell Andrei's last name.
- Name the King of PECL and the PECL Princess.
- Who started the PEAR project?
- When did Rasmus first announce PHP?
There were also plenty of crazy PHP syntax questions that seemed more like a showcase of PHP's oddest behavior than trivia questions, but I guess that's what makes it trivia. :-) Regardless, this was a fun event that everyone seemed to enjoy, and the winner walked away with a new Apple MacBook. Hopefully Sean and the other folks at php|architect will make this an annual event.
My friend and colleague Wez gave his PDO talk as well as one on mail that became known as "Not PDO" among conference attendees. :-) Sadly, I had to miss the latter, because I had an early flight on Friday, but I ended up spending almost 12 hours at the Toronto airport after four consecutive flights to New York were cancelled - not a good way to end my trip, but I enjoyed my time in Toronto and hope to be back next year.
Living in New York, it's hard to let this day pass without acknowledging the events that took place five years ago, but no words I can write seem appropriate.
I'd like to point you to an episode of the Daily Show that was broadcast a few days after the attacks.
Clearly inspired by the Google Summer of Code, OWASP has launched the OWASP Autumn of Code:
The Open Web Application Security Project (OWASP) is launching today a
new project aimed at financially sponsoring contributions to OWASP
The new project, called "OWASP Autumn of Code 2006", aims to sponsor 8
individuals (4 at $3,500 USD and 4 at $5,000 USD) to work on existing
OWASP Projects. The objective is to improve the selected projects to a
the level of completeness and professionalism required for its wide
use and deployment.
There are no geographical, age or any other form of restrictions of
who can apply for an "OWASP Autumn of Code 2006" sponsorship. The only
requirement is that the candidate shows the potential to accomplish
the project's objectives and the commitment to dedicate the time
required to complete it in the allocated time frame (projects must be
completed by 31st December 2006).
Proposals are due by 18 Sep 2006. This sounds like a really good chance to make some positive contributions to web application security.