Problem solve Get help with specific problems with your technologies, process and projects.

Addressing the dangers of JavaScript in the enterprise

The dangers of JavaScript are no secret to security professionals. Expert Michael Cobb discusses enterprise JavaScript defense technology and tactics.

JavaScript is the most common website scripting language. It’s browser agonistic and makes pages far more dynamic than is possible with plain HTML. However, it also enables hackers to subvert a browser into performing operations it shouldn't.

The prevalent use of JavaScript for malicious purposes -- many injection attacks such as cross-site scripting (XSS) make use of it -- has forced browser vendors to step up their security efforts. In this tip, we’ll discuss JavaScript security options, as well as whether enterprises should disable JavaScript altogether.

One JavaScript security approach has been to prevent users from reaching sites known to host malicious code so it never has a chance to execute. To do this, Microsoft’s IE8 and IE9 use SmartScreen URL filtering, while Firefox, Safari and Chrome rely on Google's SafeBrowsing technology. These reputation-based systems search the Internet for malicious websites and flag their content accordingly. Browsers then request reputation information for any URL a user requests and present a warning to them if its content has been flagged as potentially dangerous.

IE9 also has an integrated XSS filter feature, which analyzes how websites interact with other sites to prevent one site from adding potentially malicious script code to another. Chrome has a similar feature; Firefox users must install the free plug-in, NoScript. The problem all these controls face is that the proper sanitization of all untrusted content is challenging because a browser may interpret certain content differently from how the server intends. For example, the Samy worm took advantage of this discrepancy by splitting the word JavaScript -- a word filtered out during input validation by the MySpace website -- into two and placing the code within a CSS tag.

Also, attackers are starting to obfuscate their intentions by using combined attacks that are more complex and difficult to detect. A good example of how an attacker can reduce the effectiveness of many of the proactive security detection mechanisms is to split the malicious code between Adobe ActionScript language, built into Adobe flash, and JavaScript components on the webpage.

Version 4 of Firefox supports the concept of Content Security Policy (CSP). This allows sites to specify which domains a browser should consider valid sources of executable script in the form of .js files by sending a special header. A CSP-compatible Web browser will only execute scripts loaded from these approved domains. Twitter has recently implemented CSP for its mobile site, but it has not been an easy task; embedded JavaScript code has to be moved to separate files and then reloaded via script tags. Also, CSP disables various JavaScript-controlled HTML events like onClick. This prevents malicious use of JavaScript, but can inadvertently break legitimate onClick website functionality like user submission buttons. Although CSP is being integrated into  the WordPress, Drupal and the Django Web frameworks, it will be a long time before the majority of sites make use of CSP, particularly as it only offers limited protection against persistent XSS and none against cross-site request forgery (CSRF) attacks.

Due to the potential dangers of JavaScript, enterprises may decide to disable its execution altogether, a configuration setting offered by all browsers. However, this will render a large percentage of websites unusable; most navigation menus use JavaScript to some degree. If security is paramount, then an alternative option is to disable scripting, but build a whitelist of trusted sites to control which sites can and cannot run JavaScript in the browser. Again, all browsers support this feature, but maintaining whitelists is a time-consuming task. Disabling JavaScript in Adobe Reader should also be considered. According to Symantec Corp., last year nearly half of all Web-based attacks were associated with malicious PDF files. This control is unlikely to cause much of an inconvenience, as most PDFs don’t require JavaScript to be readable and usable.

I admit these solutions lack finesse, but there is currently no real alternative that fully secures and  allows the use of JavaScript. Although browser vendors are under pressure to make browsing safer, more onus needs to be put on Web developers to build sites that are less vulnerable to JavaScript-based attacks. For example, developers should protect website users from persistent or stored XSS attacks by applying rigorous validation to user input before adding it to a webpage or storing it in a database. (.NET developers should make full use of Microsoft’s Anti-Cross Site Scripting Library to sanitize stored data). Developers should get used to always using the HttpOnly flag to make a cookie inaccessible to client side script and learn to make use of methods like toStaticHTML introduced by Microsoft in IE8. This removes event attributes and script from user input before it is displayed as HTML, thus protecting pages against DOM-based XSS attacks. Eliminating webpages that are vulnerable to JavaScript-based attacks will provide far better protection for users.

Whatever security controls browsers or sites implement, users and sites can still fall victim to socially engineered attacks that trick the user into pasting JavaScript code into the browser address bar, which then executes in the context of the currently loaded page. These attacks prey on the weakest link in browser security: a user’s trust. To protect users from this type of self-inflicted attack, IE9 removes the “JavaScript:” prefix from any string that is pasted into the address bar. But, the best method of beating socially engineered attacks is through continuous user awareness training to ensure users understand the risks of not following security policy.

About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry and another 16 years of experience in finance. He is the founder and managing director of Cobweb Applications Ltd., a consultancy that helps companies to secure their networks and websites, and also helps them achieve ISO 27001 certification. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Michael is also a Microsoft Certified Database Administrator and a Microsoft Certified Professional.

This was last published in August 2011

Dig Deeper on Web application and API security best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.