One of the most vexing problems in helping users, engineers and systems administrators stay on the road to better security is a basic problem of semantics and a proper definition of terms. Nowhere is this better demonstrated than in the continuing confusion over JavaScript and Java.

JavaScript has been the guilty culprit in a host of browser security problems recently, giving malicious Web site operators the ability to trick a browser into deleting files, and opportunities to steal passwords and credit card numbers, as well as many other dirty deeds.
Advertisement:

Java, while not completely bulletproof, has had only a fraction of the security incidents that have been attributed to JavaScript. But does anyone know the difference? Repeat after me: JavaScript is not Java, JavaScript is not Java. . .

Java, of course, is an object-oriented language developed by Sun. The language was originally developed to be small and portable, with set-top boxes and handheld devices as the original targeted platforms. It is similar in constructs to C++; however, its compilation into machine independent bytecodes rather than native machine code gave rise to its promise of write-once, run-anywhere status. The language predated the Web, but it soon became apparent that its portability virtues made it well suited for the Internet.

JavaScript is a scripting language developed by Netscape. Its original name was Livescript, and its name was changed to JavaScript to capitalize on "the everything is Java" craze in December of 1995. Technically, Netscape now calls it ECMAScript, and Microsoft calls it Jscript, but it gained critical mass under the moniker of JavaScript.

The work of both of these companies has been incorporated into the official standard, ECMA-262 ECMAScript Language Specification. The purpose behind JavaScript is to add some dynamic capabilities to HTML, such as verifying form information before it is transmitted, creating an interactive questionnaire, or playing a sound file in response to a user action; all without requiring server-based processing.

Although in many respects JavaScript is syntactically similar to Java, it lacks Java's sandboxing, static typing and strong type checking. By not following all of the strict rules a language like Java enforces, JavaScript is a simpler programming language for the masses but also contains more capabilities for a malicious programmer to step outside of its boundaries and do damage to an end user. JavaScript is implemented directly within HTML, like a macro within Microsoft Word, whereas Java is a standalone programming language.

Java applets are compiled into byte code format and are executed by the Java Virtual Machine, which can exist inside the browser context, or can be completely separate. Java applets are linked from within HTML pages, much like you would link to a gif. The Java Virtual Machine enforces security for the applet, preventing direct access to the native file system, for example. On the other hand, JavaScript code is embedded within the HTML page with its own special tags. JavaScript is executed by the JavaScript Interpreter within the browser, and rather than executing strictly within its own environment, it can be manipulated to invoke a wide variety of resources, such as making operating system calls and starting Java applets. Indeed it is often used as a front-end interface for organizing and reusing Java applets within HTML documents.

The sandbox for Java is well defined: an applet can only communicate with the original server it was downloaded from. The protection parameters for JavaScript are less well defined, and security issues are being patched on a regular basis.

Several sample scripts have been developed by browser bug hunter Georgi Guninski that demonstrate some of the problems with malicious JavaScript applications. These JavaScript applications read local files and perform a variety of nonharmful actions to demonstrate the risks. In reviewing the scripts, it is evident that they could have been very easily modified to look for sensitive local data and send it in stealth to a Web server.

Over time, JavaScript has become widely used because of the development push it has received from Netscape and Microsoft. While it is rare to absolutely need Java support in order to run mission critical Internet applications, many Web sites use JavaScript so extensively that it is virtually impossible to use these sites without it. (Indeed, SecurityPortal.com uses a JavaScript application for our menu, although a perfectly functional HTML menu is available to those without JavaScript support.) So it is a Catch-22 for users: disabling JavaScript reduces security risks, but many sites become inoperable without it. As Ron Moritz, CTO of Finjan Software, says:

"JavaScript .. introduces security problems. Most JavaScript security violations require only minor user interaction, such as a mouse click, to activate the malicious code. By simply creating a pop-up window that asks the user to click "OK" to continue, JavaScript attack code can be executed. Based on the risks associated with known JavaScript security violations, many have advocated turning JavaScript off.

"Today, blocking JavaScript is less common. One reason is that corporate users find it necessary to run JavaScript to enable required services. Consider an application that enables browsers to be used as clients of legacy systems through custom Web pages that link to various host applications. To improve services to users the application relies on JavaScript to automate tasks such as logon sequences and menu navigation. In the travel industry, several sites have emerged that deliver services only when JavaScript is enabled. There is little doubt that blocking JavaScript or other scripting languages will not be an option for long."

This not to say that Java is free from security issues. An applet from an untrusted Web site could easily act as a Trojan Horse, presenting a fake logon screen to capture passwords and sending this information back to the untrusted server. Well-conceived social engineering can deceive users any number of ways; however, there is not as great of an inherent risk to the local computer and private data files from Java as there is from JavaScript.

The solutions to the security issues that accompany active content technologies such as JavaScript are not easy to come by. Digitally signed applets do not offer genuine protection to malicious code. Software that attempts to enforce stricter sandboxing to JavaScript applications, blocking access to local system files or other resources according to policy are needed. It also may come down to the need to "dumb down" JavaScript and cut down on some of the functionality of the language in order to restore some sanity to the balance of security.