“onMouseOver” Twitter Hack: Examining Feature Firsts vs. Application Security

Druckfreundlich, PDF & E-Mail

This morning we saw a Twitter hack (“onMouseOver”) that used a Cross Site Scripting (XSS) vulnerability to exploit the  JavaScript functionality used with Twitter.com.  According to a hack post-mortem Twitter blog post by @boblord of the Twitter security team, the XSS vulnerability was something that the Twitter engineering team discovered and fixed last month. Unfortunately a recent site update “unknowingly resurfaced” the problem.

“First” vs. Secure

While the effects of this hack ranged from benign – Twitter users exploited the script to send spam messages and tweets –  to potentially malicious – some users were redirected to adult Web sites –  it nevertheless demonstrates the challenge of balancing rich functionality with powerful security.  The point being that in the rush to release new features, security is often an afterthought.

I was at OWASP in Palo Alto, Calif., earlier this month and attended a panel session on best development practices for social network platform engineers.  One of the panelists shared a tape-recorded sound bite from a presentation he had attended at a different conference.  The clip was from an executive at a large social gaming organization who shared her views on security with that particular panel and audience.  In a nutshell, her view was that security is an annoyance and can hinder the release of new product features.  Although shocking to hear at first, I suppose I can understand her viewpoints:  in an ultracompetitive marketplace, time-to-market – or the pressure to “offer it first” –  can be the difference between market success and the collapse of the organization.  It is entirely possible that in the rush to release all the new features at the “new and improved Twitter.com,” the fixes to the XSS vulnerability that ultimately led to this morning’s attack, could have been overwritten or lost.

So what can we do?

As today’s Twitter hack demonstrates, it can be extremely difficult to create perfectly secure code, especially when there are substantial time-to-market pressures.  We’ve seen this at other social networking companies like Facebook that can fall victim to other types of hacks, such as Clickjacking attacks. Even an experienced engineering team –  like Twitter’s –  can overlook vulnerabilities that can be introduced to the product.

What Barracuda Networks recommends to our customers is that they take a proactive stance to guard against Web application vulnerabilities. There is no such thing as a silver bullet for security but there are steps that can be taken to minimize risk. The Barracuda Web Application Firewall is a key tool that mitigates vulnerabilities by inspecting and blocking malicious Web traffic from your servers. This is especially applicable during new product or new feature launches where products are at a high risk for unforeseen vulnerabilities.  Hypothetically, if Twitter had a Barracuda Web Application Firewall deployed in reverse proxy mode, it would have identified the “onMouseOver” script and either blocked it or notified the administrator who could have then take the appropriate actions to malicious content before it could be stored on Twitter’s backend Web and/or database servers and distributed to users. This would have prevented the outbreak.

Nach oben scrollen