Web 2.0 Security Part I: A MASHup of Problems

This is Part I of a series on Web 2.0 Security.

A good way to remember things is to use mnemonics, so when you're trying to list the security issues relevant to Web 2.0 just remember this: it's a MASHup.

• More of everything.
• Asymmetric data formats
• Scripting based
• Hidden URLs and code

This first episode is brought to you by the letter "M".

More of Everything

So what's that mean, "more of everything"? Well, Web 2.0, whether we're talking about applications (blogs, wikis, forums, video) or the technologies that enable the applications (AJAX, XML, RSS, RDF, etc...), simply contains more of everything than its legacy predecessors.

There are more:

• connections
• data formats
• components
• scripts

Hence, there are more attack vectors and more vulnerabilities, simply because you're combining multiple languages, technologies, and paradigms into a single, behemoth application.

On the left is a Web 2.0 application. Each of the components (different colors) use their own connection to a server side script (on the right) and use their own set of data formats to communicate.

You'll notice there is a one-to-one correlation between components and server-side scripts, and that each component sends data in one format but receives a response in another.

This is, of course, the worst case scenario. Most AJAX-based applications send in one format and receive in another, but it's fairly consistent. The problem is that you could (and many do) mix and match the formats at will, and often times you may not know what format the data will be in because you're using a toolkit.

You'll also notice that there are more scripts on the server side. That's because whether we're talking about AJAX toolkits or mashups using syndication protocols (RSS, RDF, etc...), the paradigm encourages one script per component. This makes it easier to reuse a common component across multiple applications, but introduces issues of code security and management that need to be addressed.

And finally, there are simply more connections. Not just initially, when the application is loaded, but on an ongoing basis as components perform actions such as update automatically, respond to user actions, and prefetch data.  

The Risks

The risks inherent in "more" of everything are fairly recognizable as long-standing, traditional Web-based application risks.

• More Connections. The increase in connections, and length of those connections, can inadvertently consume more resources than necessary and cause an outage, resulting in a denial of service to other users. Just as easily as this can occur inadvertently, of course, it could be accomplished with more malicious intent. Connections made via the XMLHTTPRequest object do not necessarily carry the "referrer" header, which makes the use of this object to load or pre-fetch data even more dangerous, as it may be impossible (by default) to know whether the request is coming from a legitimate site, user, or application.
  
• More Scripts. There are more server-side scripts (applications) to secure, as well as the additional burden of dealing with script (usually Javascript) on the client. Every line of code written is another opportunity for a vulnerability to be introduced. Every line of code written needs to be secured, which adds additional burdens on the server executing the code.
  
  This is especially problematic with toolkits, such as Dojo and Script.aculo.us, because these toolkits become "black boxes" for communication. Developers aren't necessarily aware of what the actual scripts - loaded onto the client - are doing, how they work, or what measures their developers took to secure the toolkit. There's almost no way for a user of the toolkit to know whether the version s/he downloaded and is using has been compromised.
  
• More components. There are more components in a Web 2.0 application, in the developer-oriented view of component as a self-contained object that combines presentation and application logic. Each component not only generally corresponds to a script on the server, but also contains code (Javascript, VBScript, ActionScript) on the client that validates, formats, parses, and otherwise manipulates user input. This script may also trigger other events, which in turn executes other script logic on the client and usually also results in another call to a another script on the server.
  
  The additonal components and their application logic represent risk because they may be black-boxes (as with toolkits), they may be third-party constructed (and sometimes even hosted), and the scripting languages on the client are human readable, potentially offering attackers information about internal schemas, formats, and processes that can be exploited.
  
• More data formats. The potential to mix and max data formats adds additional complexity to the task of securing Web 2.0 applications. The plethora of data formats primarily causes issues because it increases the number of potential attacks to which your application is vulnerable. It can also cause issues for web application vulnerability scanners that cannot adapt to multiple data formats in a single request (e.g. XML Islands).
  
  The issue of asymmetric data formats is the subject of the letter "A", which we'll discuss in the next part of this series.  

Next: Asymmetric data formats

Imbibing: Water