What if an untrusted RSS feed injects a malicious link? This link is not validated anywhere as is evident from the code. Here is an example of the RSS node:

   
   javascript:alert("Simple XSS")
   
   XYZ news
   2005-11-16T16:00:00-08:00

Note that the "href" element of XML contains JavaScript. Hence, when an end-user clicks the link the script will run in the current DOM context. This process is illustrated below in Figure 6.

Figure 6. XSS with link.

Information presentation in the DOM from an untrusted source may put an end-user's session at risk. Web 2.0 applications provide information from different sources in a single browser page.

Let's take another example to understand this attack vector clearly.

Cross-domain JSON injection

JSON is a very lightweight structure for information exchange vis-à-vis XML that has a sizeable overhead. Many applications such as Google, Yahoo and others have extended their Web services with JSON callback. With this callback in place, cross-domain information can be captured and processed in specific functions.

Let's take an example. Assume that a web site running at http://blog.example.org, has extended their services using JSON callback to allow anyone access to information using JavaScript. A JSON structure with callback name will be provided.

Access the profile for id=10 by pointing the browser to the location or by sending a GET to the following location:

Request:
http://blog.example.org/Getprofile.html?callback=profileCallback&id=10

Response:
profileCallback({"profile":[{"name":"John","email":"john@my.com"}]})

As you can see, we get JSON wrapped around profileCallback. With this callback the profileCallback() function gets executed with JSON output as its argument.

Similarly if we send id=11 we get the following response back:
profileCallback({"profile":[{"name":"Smith","email":"smith@cool.com"}]})

Our target example.comhas integrated this blog service in its application. If we scan their clien-side code and look for document.write we get the following code snippet in one of their pages: showprofile.html.

The code makes a call to "blog.example.org" which is a cross-domain and processes output in "profileCallback". By calling the page we get following output, shown below in Figure 7.

Figure 7. Simple JSON callback.

It is clear that this application running on example.com consumes third party untrusted JSON information into the application without any validation. This exposes an end-user's sensitive data such as session and cookie information.

This means that if one of the clients is trying to look up information for id=101 that has an injected JavaScript into its email field, such as the one show below, will instead have a remote malicious JavaScript run on the machine.

profileCallback({"profile":[{"name":"Jack","email":""}]})

Simply put, the victim's machine can be compromised while the victim browses through example.com's application as shown in Figure 8.

Figure 8. Possible XSS with JSON injection.

This way untrusted information processing in an AJAX virtual application sandbox can be exploited by poorly written client-side scripts or components. In this article we have covered two ways to pass on payloads to the end-user. A few other methods exist as well.

Countermeasures

To protect client-side browsers it is important to follow a re-worded maxim, "trust no third-party information." In the design phase of the application one needs to clearly define a virtual application sandbox and provide incoming information validation for all third-party sources appearing in the form of XML, RSS feeds, JSON, JavaScript arrays, etc. as shown below in Figure 9.

Figure 9. Virtual application sandbox to validate third-party information sources.

For example, prior to posting HREFs to the DOM, pass them to a simple function, such as the one shown in the code snippet below, to look for any JavaScript code injection.

function checkLink(link) {
   if(link.match(/javascript:|<|>/))
   {
      return false;
   } else {
      return true;
   }
}

It is important to filter all incoming traffic before it hits the DOM in a browser-side application sandbox - a final defense for the end-user.

Conclusion