Web 2.0 technologies are spawning an explosive growth in client-side processing (Ajax/Flex), distribution of executable content (JSON), and the mixing of code from multiple sources (Mashups).
These represent architectural decisions in applications and their underlying frameworks that were made in order to improve user experience and application functionality. However, if we are not careful, these design decisions will also lead to an explosion in vulnerabilities that can be exploited both on the client and the server.
One of the major underpinnings of “Web 2.0” is the introduction of rich client interfaces based on Ajax or Adobe’s Flex platform. These technologies can greatly enhance the web user experience transforming it from simple web forms to the direct manipulation of a rich set of UI controls typically found only in desktop software today.
Historically, whenever we depend on more software outside our control on the client or on executable content shared between programs, we see an increase in vulnerabilities. So here comes this next giant new trend and this one is the perfect storm.
Not only are we going to push code onto the client and pass around scripting code, we are also going to mashup all this code and content from multiple servers on a single client. Andrew Jaquith from Yankee Group termed it best in his 10/2007 research report – “The Web 2.0 Security Train Wreck”.
Web 2.0 applications and frameworks encourage developers to put more code on the client, ideally to enhance client side usability. But this will lead many developers to mistakenly put business logic and other critical code into the client without understanding the resulting security implications.
More code on the client is fine, if that code is all eye candy to enhance the user experience. It is definitely is not okay to put validation out there, and it’s absolutely not okay to put security controls out there.
While Web 2.0 will create a wave of vulnerable systems, it doesn’t necessarily mean that there are going to be new types of vulnerabilities: many of these problems are a rehash of the same old stuff that has simply found a new home. There’s going to be cross-sight scripting (XSS) explosion.
We must become better at recognizing these problems in the abstract if we are ever going to build things right the first time. Building things wrong, then waiting for the security community to find the mistakes (while the criminals exploit them), and then reworking everything is a major waste of development capacity and an unnecessary risk for businesses that increasingly depend on these systems.
What do we need to do to prepare for the Web 2.0 Train Wreck?
To borrow a couple cliché’s: this train has already left the station and there is no stuffing the genie back in the bottle.
Your company is going to deploy lots of Web 2.0 technology and it will put your business at risk. What you can do is make sure that your security team is working closely with your software development teams (internal and 3rd party). Stay on top of the vulnerabilities and exploits as they become public and be sure you have a quick response setup to mitigate and repair any of your software applications that have Web 2.0 vulnerabilities.
At the same time we can all work on making sure software developers and system designers understand fundamental security concepts so that Web 3.0 can deliver on the astonishing functionality it will surely promise without putting our systems and data at such risk.