Thursday, February 7th, 2008

Security Focus: JavaScript Global Namespace Pollution

Category: JavaScript, Security

Security should always be a concern when developing client-side applications as time and time again, sites have been compromised by a lack for forethought into how users, especially malicious ones, interact with your site. is an excellent site for staying abreast of new security exploits and the team constantly pushes the boundaries of how to exploit systems in an effort to educate the public and make systems more secure.

GNUCitizen founder pdp just published an article on how to detect malware via the JavaScript global namespace:

Namespace pollution checks are very trivial to perform. The check should be performed from a safer location such as outside of the execution sandbox or somewhere on the top before and after the user input is taken into consideration. The check is very simple really. All that needs to be done is to compare the list of registered objects with the expected list of objects. If they defer, the namespace has been polluted by something. The check can be performed by a function similar to the one discussed by the Atom database over here:

[language]function walkJSON(j, c) {
for (var i in j) {
c(i, j[i]);

if (j[i] instanceof Array || typeof(j[i]) == ‘object’) {
arguments.callee(j[i], c);

He goes further to explain how malware authors could bypass this check using closures:

[language](new function (window, document) {
// [evil code here]
})(window, document);[/language]

This technique will safely execute malicious code without the need to worry about polluting the whichever namespace, as long as the evil code that is enclosed within the closure does not modify the window or the document objects. DOM manipulation is acceptable since no one is crazy enough to check for DOM changes. The document object is far more complicated and walking its is hard.

So here are some questions for the Ajaxian readers:

  • Is this a big issue that merits further attention?
  • If so, what can be done to mitigate the risks?
  • What are the scenarios in which something like this could occur?

Ajaxian readers are some of the best JavaScript developers out there and I’m positive that collectively, we can determine how high of risk factor this. Either way, it’s always good to stay informed and I’m looking forward to seeing more JS security articles from GNUCitizen in the future.

Posted by Rey Bango at 10:31 am

3.5 rating from 12 votes


Comments feed TrackBack URI

If you are allowing third party scripts on your page (as is often done with advertising), you are pretty much at their mercy, currently. There is very little that can be done to hide the sensitive information (that might be stored in cookies, on the page, or sent on requests), or preventing malicious behavior (manipulating DOM, cookies, requests). As this article points out, checking for global modifications doesn’t help. The browser is very limited in it’s ability to sandbox execution. Within a frame, there is essentially unlimited access to resources (whether the code is from the origin server, or another server). Between frames, communication is severely limited (FIM). This is a major area of research and focus for future browser revisions.

Comment by kriszyp — February 7, 2008

There’s also the Google Caja project for fixing this in the client side with current browsers. We can’t solve this problem without sandboxing untrusted scripts, one way or another. Short of sandboxing, this discussion is likely to cascade into a game of coyote and roadrunner.

Comment by Kris Kowal — February 7, 2008

@Kris: One can certainly sandbox code by precisely the same manner which is explained in the 2nd code block of this post… via closures. If one makes sure app code with sensitive data is executed within privately scoped closures, and steer clear of the global namespace, you’re doing pretty good really. There’s no way for 3rd party code to find a private variable within a closure’s lexical pad as long as that variable is never attached to any global instance. Cheers :)

Comment by RyanGahl — February 8, 2008

When talking about “proper” malware, ie. stuff that is on your computer, it could be relatively easy to abuse things like User JavaScript in some browsers. In theory, you could chuck in a malicious UserJS file which runs on a banking website for example, and collects your information and sends it along.

Comment by Jani — February 8, 2008

Leave a comment

You must be logged in to post a comment.