Déjà vu – Are we building yet another bubble?
Web 2.0 certainly allows us all to innovate in the Internet. Unfortunately, just as happened in the early 1990’s Internet boom, businesses and individuals are rushing the deployment of these new Web capabilities and features with little, if any, regard to security.
Hence, we find ourselves in a position now, due in large part to rushed Web 2.0 implementations, that the Internet is a much more dangerous place to be than it has ever been. Web-based email providers, photo sharing Websites, blogs, Wikis and social networking sites have all fallen victim to malicious hackers due to their lack of consideration of security in the “new” Web 2.0 world.
In the new Web 2.0 world, the thing you reach for may look like a book, but may not be a book at all; instead, it may be something else altogether—something disguised to look like a book, possibly a bomb that explodes upon contact. The lesson? Beware. To quote an old phrase, you cannot judge a book by its cover in the new World Wide Web.
What’s Secure?
The Web now incorporates a myriad of technology innovations such as highly interactive page content, real-time updates from RSS feeds, and we have also embraced asynchronous programming languages and Internet protocols (i.e. AJAX) that dramatically enhance the users’ interactive experience.
When discussing Web 2.0 security, keep this dynamic in mind: AJAX is not insecure but many insecure Websites are today built with AJAX.
Over time, we have vetted the majority of security issues with the underlying protocols for Web 1.0. Today, however, the layering of new next-generation programming languages on top of these protocols in Web 2.0 has given the Internet’s bad guys a whole new set of opportunities to exploit.
A great example of this would of course be AJAX , the popular Web 2.0 programming language. The asynchronous nature of AJAX clearly improves the users experience on a Website by taking interactivity to an entirely new level. However, it also dramatically increases the chances that things can go terribly wrong from a security perspective.
Here’s why: Older synchronous programming languages restricted interaction to that of a defined and orderly format—safeguarding us all from security chaos. In stark contrast, AJAX operates asynchronously, whereby actions do not necessarily follow a defined orderly format.
The result: it’s nearly impossible to fully vet out any potential bugs that could result in security issues. All of the risks associated with any programming language (such as race conditions, code correctness, object violations and incorrect error handling) are amplified significantly when operating in an asynchronous environment such as that provided by AJAX.
The mere use of AJAX in Web 2.0 applications can increase the possible threat envelope due to the increased interactivity with the user’s browser. Further, if the Website-based AJAX program also needs to interact with JavaScript that runs on the user’s browser, an additional security risk is now added to the risk equation.
Some pundits argue that AJAX by-and-of-itself is not at fault and that AJAX does not increase the threat envelope. Instead, they would argue, the real issue is AJAX programmers. By using AJAX to increase application functionality, the programmer theoretically increases the possible number of server-side vulnerabilities.
This argument actually supports my original position. I never said bugs within AJAX were causing the threat envelope problem. I clearly said it is the “use” of AJAX that increases the possible threat envelope.
One final point on AJAX: It is relatively new, and secure programming standards have not yet been fully vetted. As a result, traditional Website vulnerabilities to attacks like XSS (Cross Site Scripting) could start re-appearing in Web 2.0 Websites.
Consider this: The worm that was used to attack MySpace (enabled by AJAX), as well as the worm that was used to attack Yahoo! (also enabled by AJAX) both took advantage of a component of AJAX called XHR to help propagate the worms.
Article by: Paul A. Henry Vice President, Technology Evangelism, Secure Computing