News

What’s Secure?
When discussing Web 2.0 security, keep this dynamic in mind: AJAX is not insecure but many insecure Websites today are 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 the 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.

Déjà vu – Are We Building Yet Another Bubble?
Web 2.0 certainly allows us all to innovate on the Internet. Unfortunately, similar to what 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 e-mail 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.

Internet Threat Vectors
In their quest to harness the power of the Internet, enterprises began increasing the connectivity of their internal applications to the Web. The threat vector originally involved layer 4 (the network layer) of the OSI model, where inspection is primarily limited to an IP address and port numbers in stateful packet filters. But the threat vector soon shifted to layer 7 (the application layer), where attackers could exploit the vulnerabilities of Internet-connected applications.

Now, for the problem: As the threat vector shifted from layer 4 to layer 7, our defenses simply did not keep pace,

With the change in the threat vector, signatures for known attacks began to find their way into firewall security products. Some stateful packet filter vendors attempted to offer at least some level of application layer attack protection. This protection methodology is often called a Negative Security Model, whereby all traffic is allowed to flow freely and the protective mechanism uses the signature of known attacks layered on top of their Stateful packet filters. This approach attempts to enumerate potentially malicious traffic and to block it only once (and if) it has in fact been identified.

Unfortunately, the Negative Security Model is only reactive in nature. Admittedly, these products are marketed as being proactive because of their ability to automatically block an attack on behalf of the product user. However, a signature for a given attack must first be created before any defense against that particular attack can be afforded. As a result, the use of this methodology in reality is not at all proactive and is at best only a reactive methodology. In today’s environment, where over 6,000 application vulnerabilities are reported annually, vendors are having a difficult time maintaining defensive signatures for these known attacks.

What about all the unknown threats circulating across the Web? A recent study found that the typical vulnerability exists for up to 348 days before public disclosure. Hence the malicious hacker who found the vulnerability could potentially have free rein for nearly a year to exploit a vulnerability before a defensive signature can be created.

The problems don’t end there. In a recent article, IBM warned that there is a colossal difference between the number of vulnerabilities disclosed publicly and the number of vulnerabilities that are discovered and are not publicly reported. IBM has estimated that up to 139,362 vulnerabilities are discovered annually – but not reported publicly.

Remaining Application-Layer Risks with Web 2.0
Clearly, the increased functionality of Web 2.0 Websites along with the relatively new underlying programming languages are creating new threat vectors and revitalizing traditional threat vectors. The most common and “most concerning” threat vectors for Web 2.0 include:

• Web-borne malware
• Real-time RSS/Atom Feeds with JavaScript Malware inside
• XSS Scripting (Cross Site Scripting) – e.g., MySpace Worm
• CSRF (Cross Site Request Forgeries) – Stealing data in Java space, e.g., Gmail
• XSS filter bypassing – ENCODING
• Exponential XSS Attacks – No need to limit to one Website
• Forging “request headers” using Flash
• Backdooring Media Files – JavaScript in everything
  
  

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...