(3) JS Array poisoning

JS array is another very popular object for serialization. It is easy to port across platforms and is effective in a cross-language framework. Poisoning a JS array spoils the DOM context. A JS array can be exploited with simple cross-site scripting in the browser. Here is a sample JS array:

new Array(“Laptop”, “Thinkpad”, “T60”, “Used”, “900$”, “It is great and I have used it for 2 years”)

This array is passed by an auction site for a used laptop. If this array object is not properly sanitized on the server-side, a user can inject a script in the last field. This injection can compromise the browser and can be exploited by an attack agent.

(4) Manipulated XML stream

An Ajax call consumes XML from various locations. These XML blocks originate from Web services running on SOAP, REST or XML-RPC. These Web services are consumed over proxy bridges from third-parties. If this third-party XML stream is manipulated by an attacker then the attacker can inject malformed content.

The browser consumes this stream from its own little XML parser. This XML parser can be vulnerable to different XML bombs. It is also possible to inject a script in this stream which can again, lead to cross-site scripting (XSS). XML consumption in the browser without proper validation can compromise the end-client.


(5) Script injection in DOM

The first four holes were the result of issues with serialization. Once this serialized stream of object is received in the browser, developers make certain calls to access the DOM. The objective is to “repaint” or “recharge” the DOM with new content. This can be done by calling eval(), a customized function or document.write(). If these calls are made on untrusted information streams, the browser would be vulnerable to a DOM manipulation vulnerability. There are several document.*() calls that can be utilized by attack agents to inject XSS into the DOM context.

For example, consider this line of JavaScript code, Document.write(product-review)

Here, “Product-review” is a variable originating from a third-party blog. What if it contains JavaScript? The answer is obvious. It will get executed in the browser.

(6) Cross-domain access and Callback

Ajax cannot access cross-domains from the browser. One of the browser security features that exists in all flavors of browsers is the blocking of cross-domain access. There are several Web services that provide a callback mechanism for object serialization. Developers can use this callback mechanism to integrate Web services in the browser itself. The callback function name can be passed back so that as soon as the callback object stream is retrieved by the browser it gets executed by the specific function name originally passed from the browser.