Earlier this week, yet another rapidly spreading MySapce worm reminded me of a frequent dilemma in computer security. All too often functionality is added to technology without first considering its security implications. The latest MySpace worm was made possible by a feature that Apple embedded in QuickTime files some time ago called HREF Tracks. The intentions for adding HREF tracks were certainly good. This feature would allow the viewing of a QuickTime movie to be a more interactive experience as complimentary web pages could be loaded in the background at predefined intervals during playback. For the truly adventurous, JavaScript commands would be executed to produce dynamic client side content. [This is the moment at the party where the music suddenly stops and people freeze in their (HREF) tracks.] Allow embedded JavaScript to be auto executed when viewing a movie!?! Can't these same movies start playing when a user simply visits a web page?!? What were they thinking! They weren't, at least not from a security standpoint. This is a prime example of why security needs to be embedded throughout the software development lifecycle. I have no doubt that there was plenty of backslapping and high fives at the development meeting when this feature was suggested. Programmers were anxious to develop the cool new technology, the marketing team could hardly wait to brag about this exciting differentiator and finance started counting dollar signs, but where was the security team? Either they weren't invited to the meeting or hadn't had enough coffee that morning. It didn't take an expert to predict the potential consequences yet several did.

While this latest incident leaves some egg on the collective faces of the security geeks at Apple and MySpace, they shouldn't feel lonely. We've had plenty of examples of good intentions leading to bad security and here are a few of my favorites.

Default Passwords

Forgot the password to your company router? No need to worry, chances are that it's listed in one of the many online default password lists. Why can't hardware/software vendors force users to select a unique password when they first use the technology? Are we as human beings incapable of remembering passwords? Well perhaps, more on that next.

Strong Passwords

Sometimes security can go too far. In our overzealous effort to increase password security, we've asked users to remember 26 character, alphanumeric, upper/lower case, 3 symbol passwords that change weekly. Yes, "Th1siZ@hArdP@ssw3rdToGu3sS" is certainly harder to crack than "cat", but the human mind has its limitations. While we have poor memory capacity, we are able to adapt and plenty of cubicle dwellers have turned to the ever present sticky note to combat their evil sysadmin. If password security is a concern at your organization (and it should be) opt for two factor authentication. It's finally at a point where even the sticky note crowd can use it.

Error Messages

Error messages let us know when something has gone wrong. All too often, they tell us too much. In the case of SQL injection, verbose error messages that should have been disabled in the first place, facilitate the information necessary to allow an attacker to inject SQL commands. When brute forcing the login screen of a web application, helpful error messages may also tell an attacker if a targeted username exists on the web site. As your mother taught you, if you can't say something secure, say nothing at all.

Robots.txt Files

Robots.txt files are not themselves a security risk. Security does however become a problem when uninformed webmasters mistakenly believe that they can be used to protect content on a web site. A robots.txt file provides a means of communicating to third party spiders, most notably those of search engines, which files and directories should not be indexed. Search engines respect these files but hackers don't. While a robots.txt file will keep your secret content out of the Google search index, it will also provide a blueprint for would-be-hackers wondering which information you consider precious. Need a good example of an over bloated robots.txt file? Look no further than 1600 Pennsylvania Avenue. But be careful hackers...wise web masters may use a little reverse psychology to turn a robots.txt file into a spider trap.

Client Side Code

A trend in so called Web 2.0 applications is to have your users build a web site for one another instead of building it for them. Social networking sites such as MySpace are leading the charge, freely allowing users to upload client side script including HTML and JavaScript in order to create a more dynamic user experience. Not surprisingly, this trend has resulted in web application worms such as Samy, Yamanner and the latest MySpace QuickTime worm mentioned previously. Despite the obvious security concerns associated with turning users into programmers, perhaps the trend continues as rapid growth outweighs security when millions of dollars are on the line.

Do-Not-Spam-List

This one still makes me chuckle - let people register their email addresses and politely ask spammers to respect their privacy. Good plan - send a list of email addresses to spammers. Fortunately, logic emerged at the FTC and they realized that law breakers tend not to adhere to laws.

Sample Applications and Extended Functionality

Revisiting the insecure by default theme, we need to look at technologies which include sample applications and extended functionality that are enabled by default. Microsoft's Internet Information Services (IIS) team learned this lesson the hard way after vulnerabilities were discovered in .printer and .htr ISAPI extensions which were required by few users but enabled by default. Fortunately, Microsoft learned from the painful security lessons taught by past versions of IIS and implemented their Trustworthy Computing Initiative prior to developing IIS 6.0.

Code Comments

As a child you no doubt witnessed your parents enjoying a glass of wine only to be told that it was good for grown-ups and bad for children. Code comments are like wine. Good for programmers, but bad for hackers. All too often, comments are included in code as an effort to share ideas among developers but aren't removed prior to the code being released into production. Those same helpful comments can be a goldmine for hackers when they reveal details about the system. Finding these forgotten comments became a whole lot easier thanks to Google Code Search.

Embedded Web Servers

Today, everything from your printer to your router (and possibly even your toaster) has a built in web server. Why? Why not. Every good appliance needs an administrative interface and what's more user friendly than a web page? The problem with these servers is that they tend to be small proprietary applications that have not undergone the same security scrutiny as traditional web servers. In our experience they are chock full of vulnerabilities and to make matters worse, security patches are rarely released or applied. Don't care if your printer is compromised? Perhaps you'd be more concerned if traffic from the switch in the finance department were rerouted.

Conclusion

How do we avoid these pitfalls? Before you get too excited about a new feature or product, ask your resident security geek for his opinion. Sure he's overly paranoid and somewhat anti-social but he makes the big bucks for a reason. Security starts at the design phase, not the production phase.

- michael