Web 2.0 Entails 'Sleeping Giant' Security Risk
- By John K. Waters
As increasing numbers of enterprises climb aboard the Web 2.0 bandwagon, it's more important than ever for software developers to keep security in mind during the development process. So says Danny Allan, director of security research at Watchfire, the Waltham, MA-based Web-app security company acquired by IBM in July. Allan was in Santa Clara, CA to speak at this year's AjaxWorld show, and he took a few minutes to talk with me before his presentation.
The two top vulnerabilities affecting Web 2.0 applications today, Allan said, are cross-site scripting (CSS) and cross-site request forgery (CSRF).
"CSS is nothing new," he said, "but the attack vectors and the way in which it is used in Web 2.0 applications is very different and much more dangerous. And CSRF is the sleeping giant. It hasn't been exploited much to date, but it's looming large on the horizon."
CSRF is a malicious Web site exploit in which an attacker fakes a request to a site. CSRF is similar to CSS, but where CSS requires crackers and malicious hackers to inject unauthorized code into a Web site, CSRF simply transmits unauthorized commands seemingly from a user the Web site trusts.
"In a cross-site attack, a malicious individual attacks a victim," Allan explains. "Say you're on your banking Web site, and I get control of your browser. I can essentially force you to log into your banking application and transfer funds to my account. Request forgery provides the site with a legitimate request; it exploits the way the Web works, which performs actions based on input from trusted and authenticated users without requiring the user to authorize a specific action. The challenge for organizations is, they don't know when the request is legitimate or it has been forced upon them."
Web 2.0 makes all of this a bit worse, Allan said, because every interaction isn't initiated by the user. The AJAX framework underneath makes many of these requests, so it becomes more and more difficult to tell whether the request came from the user.
The attacks are new, but the causes haven't changed.
"I think one of the problems is that we focus too much on the latest Web 2.0 attacks, and not on why that attack worked," Allan said. "The 'why' hasn't changed. If we build security into the software development lifecycle and consider things like input validation stringently and output encoding--all these things we've all been talking about for 15 years--we'll solve these problems."
One of the best things the industry has done to improve application security, Allan says, is implementing mature frameworks, like Java EE, .NET, and Struts. One of the challenges in the Web 2.0 world is that the frameworks for that environment have yet to achieve that same level of maturity.
Allan advises Web 2.0 developers to shift their approach to security essentially in the same way that many have shifted their approach in the overall development process: from a traditional waterfall approach to what amounts to an agile or lightweight approach. And his advice for app-dev managers who want to get their developers to be more security minded: Don't try to "boil the ocean" and test for everything. Pick the top couple of security risks--say, CSS and CSRF--and do an incremental rollout.
"You don't want to fire hose the developers with too many security tests," he said. "It becomes overwhelming and they end up not doing anything. If we do incremental and ongoing iterative testing, it's manageable."