Security Focus: JavaScript Global Namespace Pollution
Date : 2008 02 07 Category : Tech & Development
AjaxianSecurity 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. GNUCitizen.org 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:
PLAIN TEXT 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:
PLAIN TEXT LANGUAGE:(new function (window, document) {
// [evil code here]
})(window, document);
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.