frogcake.net

I’ve just been to a very interesting BOF by Ludovic Champenois at JavaOne about the new PHP support in NetBeans. The talk was in the context of the new OpenSolaris WebStack so some time was spent on this, including the unique DTrace functionality which looks neat, but I found the NetBeans demo the most interesting.

NetBeans has great support for Ruby and JavaScript and now PHP is starting to get some of that goodness too. At the moment it is only available as either an Early Access release with just the core PHP stuff or in NetBeans trunk (6.5) but it looks very promising. It has:

• code completion
• PHP documentation
• variable renaming
• source navigation
• goto type
• extensible templates and auto-comments
• integrated debugging with XDebug

Sure, you don’t get all the neat refactoring you can have with a statically typed language like Java but even just the variable/method/class renaming is a big help. The code completion is good and the navigation even works over the filesystem in ‘require’ statements. Debugging works just like normal NetBeans debugging including all the usual stuff like call stack, mouse-over variable values, step-in/out, etc. A JMaki plugin brings all that goodness as well.

It’s still fairly early days but it looks pretty neat and maybe PHP finally has a good open source IDE.

This was a popular session. The queue stretched down the hall, out the front door and around the block. It covered the main vulnerabilities bad guys exploit to attack websites. It was a good session given by Joe Walker who also gave the BOF on Comet.

First up was cross-site request forgery or CSRF. This is basically misusing people’s cookies. For example if a user is logged in to bank.com on one tab and then they visit evilsite.com on another tab it is possible to do something like: <iframe src=”bank.com/transfer?amt=all&dest=dr_evil” />. No JavaScript required. The only real way to prevent CSRF attacks is to include some kind of authentication token in every request that is separate from the cookie, like a hash of the user’s session ID. These tokens shouldn’t be in GET requests as they could cause problems with bookmarks, etc and GET requests should be idempotent. So a hidden POST field is better. You can use the OWASP servlet filter to add these hidden fields.

He also covered JSON hijacking and the old favourite, XSS. An interesting point was that if your site has an XSS vulnerability that will allow bypassing of any CSRF protections you may have put in place. One of the biggest problems for preventing XSS is that browsers will render any old crap. Basically the web is broken.