OSCON 2006 was a lot of fun for a lot of reasons, and was overall a very positive experience.  There were a few things that bugged me, though.

I met a lot of cool people at OSCON.  There are too many folks to list here without either getting really boring or forgetting someone, but I was happy to put a lot of faces to names and exchange ideas with some Very Smart People.  The PHP Security Hoedown BOF that I moderated was especially good in that respect, I thought.  There were also a lot of good sessions, especially Theo Schlossnagle’s Big Bad PostgreSQL: A Case Study, Chris Shiflett’s PHP Security Testing, and the PHP Lightning Talks (“PHP-Nuke is a honeypot” - thank you for the best quote of the convention, Zak Greant).

On the other hand, I was very surprised that the Security track at OSCON was almost nonexistent.  There were four sessions and one tutorial, and for a 5-day event with lots of sessions going on at the same time, that seems like a really poor showing.  The only other tracks that has security-related sessions were:

• Linux (including one shared with the Security track)
• PHP

which leaves us with the following tracks with no security-oriented sessions:

• Business
• Databases
• Desktop Apps
• Emerging Topics
• Java
• JavaScript/Ajax
• Perl
• Products and Services
• Programming
• Python
• Ruby
• Web Apps
• Windows

I can certainly think of a few pertinent security topics for each of these tracks.  I’m not affiliated with O’Reilly, and I have no idea whether the OSCON planners just didn’t get very many security-related proposals, or they felt that attendees wouldn’t be interested in them.  Either way, it’s worrisome.

Security is an essential part of any kind of development: as fundamental as interface design or performance.  Developers are stewards of the data of their users, and if we don’t take that responsibility seriously, all our sweet gradient backgrounds and performance optimizations are pointless.  So to see, for one reason or another, security relegated to steerage at OSCON was disappointing.  I hope O’Reilly works hard to correct this next year, and I’m going to encourage other CERIAS folk like Pascal Meunier and Keith Watson to send in proposals for 2007.

Chris Shiflett has posted a good piece in his blog on the potential danger of cross-domain AJAX scripting (digg here).  When Chris and I discussed this at OSCON, I was pretty surprised that anyone would think that violating the same-origin restrictions was in any way a good idea.  His post gives a good example of how dangerous this would be.

Just a reminder: next week I’ll be in Portland at OSCON 2006.  I’ll be moderating the PHP Security Hoedown wednesday night.  If you’re interested in meeting up and talking about web app security stuff or CERIAS, please drop us a line at oscon@cerias.purdue.edu.

Myspace, the super-popular web site that your kid uses and you don’t, was once again hit by a worm, this time utilizing Macromedia Flash as its primary vector.  This was a reminder for me of just how badly Myspace has screwed up when it comes to input filtering:

• They use a “blacklist” approach, disallowing customized markup that they know could be an issue.  How confident are you that they covered all their bases, and could anticipate future problems?  I don’t trust my own code that much, let alone theirs.
• They allow embed HTML tags.  That means letting folks embed arbitrary content that utilizes plugins, like… Flash. While Myspace filters Javascript, they seem to have forgotten that Flash has Javascript interaction and DOM manipulation capabilities.  If you’re a Myspace user, you may have noticed Javascript alert()-style pop-up windows appearing on some profiles—those are generated by embedding an offsite Flash program into a profile, which then generates Javascript code.

Even if they can plug these holes, it’s unlikely that anything short of a full rewrite/refactorization of their profile customization system can ever be considered moderately secure.

So will Myspace get their act together and modify their input filtering approaches? Very unlikely.  A large portion of Myspace’s appeal relies upon the customization techniques that allow users to decorate their pages with all manner of obnoxious flashing, glittery animations and videos.  Millions of users use cobbled-together hacks to twist their profiles into something fancier than the default, and a substantial cottage industry has sprung up around the subject.  Doing proper input filtering means undoing much of that.

Even if relatively secure equivalent techniques are offered, Myspace would certainly find themselves with a disgruntled user base that’s more likely to bail to a competitor.  That’s an incredibly risky move in the social networking market, and will likely lead Myspace to continue plugging holes rather than building a dam that works.

This is why you can’t design web applications with security as an afterthought.  Myspace has, and I think it will prove to be their biggest mistake.

Via Infinite Loop, I came across an interesting post from a hawdcore MacBook Pro user who bellied up to the bar and retrofitted a Sony fingerprint scanner into his precious Apple laptop.  No indication that the hardware actually interfaces at all with OS X, but it’s pretty cool, and maybe Apple will get some inspiration from this. 8)