Search /
Docfinder:
Advanced search  |  Help  |  Site map
RESEARCH CENTERS
SITE RESOURCES
Click for Layer 8! No, really, click NOW!
Networking for Small Business
TODAY'S NEWS
FCC defends new net neutrality proposal
New iPad rumor rollup for week ending April 23
Dell adds Big Switch to its SDN mix
Google Plus now minus chief Vic Gundotra
Heartbleed prompts joint vendor effort to boost OpenSSL, security
Microsoft Surface Mini seems likely to ship soon
China working on Linux replacement for Windows XP
FCC adds $9 billion to broadband subsidy fund
Raspberry Pi alternatives emerge to fill need for speed
It's now possible to wirelessly charge 40 smartphones from 16 feet away
Ex-FCC commissioner to head CTIA in latest Washington shuffle
Go time traveling with Google Maps
While Heartbleed distracts, hackers hit US universities
Survey respondents shun much-hyped mobile shopping technologies
7 Ways to Advance Your Project Management Career
How Apple's billion dollar sapphire bet will pay off
US to vote on sharp increase in broadband subsidies
iPhone 6 rumor rollup for the week ending April 18
NSA spying revelations have tired out China's Huawei
Arista co-founder may have switch maker by its jewels
Open source pitfalls – and how to avoid them
AT&T's expanded 1 Gbps fiber rollout could go head to head with Google
Verizon: Web apps are the security punching bag of the Internet
/

JavaScript is not Java

Jim Reavis
Network World on Security, 12/01/99

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.

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.

RELATED LINKS

Jim Reavis, the founder of SecurityPortal.com, is an analyst with over 10 years' experience consulting with Fortune 500 organizations on networking and security-related technology projects. SecurityPortal.com is a Web site dedicated to providing IT professionals with comprehensive information about network security issues. Jim can be reached at jreavis@securityportal.com.

ECMA-262 ECMAScript Language Specification

Georgi Guninski's script site

Archive of Network World on Security newsletters

Network World Security Alert will keep you up to date on the latest security holes and patches, with daily updates from key vendors, security organizations and Network World reporters. See the latest dispatches from the security here.


NWFusion offers more than 40 FREE technology-specific email newsletters in key network technology areas such as NSM, VPNs, Convergence, Security and more.
Click here to sign up!
New Event - WANs: Optimizing Your Network Now.
Hear from the experts about the innovations that are already starting to shake up the WAN world. Free Network World Technology Tour and Expo in Dallas, San Francisco, Washington DC, and New York.
Attend FREE
Your FREE Network World subscription will also include breaking news and information on wireless, storage, infrastructure, carriers and SPs, enterprise applications, videoconferencing, plus product reviews, technology insiders, management surveys and technology updates - GET IT NOW.