| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

JavaScript

Page history last edited by PBworks 15 years, 8 months ago


 

 

Java Script

 

 article

 

Background

Java Script is a scripting language most often used for client-side web development. Its standardized name is ECMAScript, though "Java Script" is much more commonly used. "Java Script" is actually Netscape Communications Corporation's (and now the Mozilla Foundation's) implementation of the ECMAScript standard.

 

Java Script is a dynamic, weakly typed, prototype-based language with first-class functions. Java Script was influenced by many languages and was designed to have a similar look to Java, but be easier for non-programmers to work with. The language is best known for its use in websites (as client-side Java Script), but is also used to enable scripting access to objects embedded in other applications.

 

Despite the name, Java Script is unrelated to the Java programming language; though both have a common debt to C syntax. The language was renamed from LiveScript in a co-marketing deal between Netscape and Sun in exchange for Netscape bundling Sun's Java runtime with their browser, which was dominant at the time. Java Script semantics is much more similar to the Self programming language.

 

"Java Script" is a registered trademark of Sun Microsystems, Inc. It was used under license for technology invented and implemented by Netscape Communications and current entities such as the Mozilla Foundation.

 

Use in Web pages

 

See also: Ajax (programming)

 

The primary use of Java Script is to write functions that are embedded in or included from HTML pages and interact with the Document Object Model (DOM) of the page. Some simple examples of this usage are:

 

  • Opening or popping up a new window with programmatic control over the size, position and 'look' of the new window (i.e. whether the menus, toolbars, etc. are visible).

Validation of web form input values to make sure that they will be accepted before they are submitted to the server.

 

  • Changing images as the mouse cursor moves over them: This effect is often used to draw the user's attention to important links displayed as graphical elements.

 

  • Because Java Script runs on the client rather than the server, it can respond to user actions quickly, making an application feel more responsive. Furthermore, Java Script code can detect user actions which HTML alone cannot, such as individual keystrokes. Applications such as Gmail attempt to take advantage of this: much of the user-interface logic is written in Java Script, and Java Script dispatches requests for information (such as the content of an e-mail message) to the server. The wider trend of Ajax programming similarly seeks to exploit Java Script's strengths.

 

 

Compatibility considerations

Main articles: Web Interoperability and Web accessibility

DOM interfaces are not part of the ECMAScript standard, or of Java Script itself. Officially, they are defined by a separate standardization effort by the W3C; in practice, browser implementations differ from the standards and from each other, and not all browsers execute Java Script.

 

To deal with these differences, Java Script authors can attempt to write standards-compliant code which will also be executed correctly by most browsers; failing that, they can write code that checks for the presence of certain browser features and behaves differently if they are not available.3 In some cases, two browsers may both implement a feature but with different behavior, and authors may find it practical to detect what browser is running and change their script's behavior to match.45

 

Furthermore, scripts will not work for all users. For example, a user may:

 

  • use an old or rare browser with incomplete or unusual DOM support,
  • use a PDA or mobile phone browser which cannot execute Java Script,
  • have Java Script execution disabled as a security precaution,
  • or be visually or otherwise disabled and use a speech browser
  • To support these users, Web authors can try to create pages which degrade gracefully on user agents (browsers) which do not support the page's Java Script.

 

 

Security

Java Script and the DOM provide the potential for malicious authors to deliver scripts to run on a client computer via the Web. Browser authors contain this risk using two restrictions. First, scripts run in a sandbox in which they can only perform Web-related actions, not general-purpose programming tasks like creating files. Second, scripts are constrained by the same origin policy: scripts from one Web site do not have access to information such as usernames, passwords, or cookies sent to another site. Most Java Script-related security bugs are breaches of either the same origin policy or the sandbox.

 

 

Cross-site vulnerabilities

Main articles: Cross-site scripting and Cross-site request forgery

A common Java Script-related security problem is cross-site scripting, or XSS, a violation of the same origin policy. XSS vulnerabilities occur when an attacker is able to cause a trusted Web site, such as an online banking website, to include a malicious script in the webpage presented to a victim. In that example, the script can then access the banking application with the privileges of the victim, potentially disclosing secret information or transferring money without the victim's authorization.

 

XSS vulnerabilities can also occur because of implementation mistakes by browser authors.6.

 

XSS is related to, but not the same as, cross-site request forgery or XSRF. In XSRF, one website causes a victim's browser to generate fraudulent requests to another site, with the victim's legitimate HTTP cookies attached to the request. Java Script hijacking is an important example of XSRF.

 

 

Misunderstanding the client-server boundary

Client-server applications, whether they involve Java Script or not, must assume that untrusted clients may be under the control of attackers. Thus any secret embedded in Java Script could be extracted by a determined adversary, and the output of Java Script operations should not be trusted. Some implications:

 

Web site authors cannot perfectly conceal how their Java Script operates because the code is sent to the client and obfuscated code can be reverse engineered.

Java Script form validation only provides convenience for users, not security. If a site verifies that users agreed to the terms of service, or filters invalid characters out of fields that should contain numbers, it must do so on the server, not only the client.

It would be extremely bad practice to embed a password in Java Script (where it can be extracted by an attacker), then have Java Script verify a user's password and pass "password_ok=1" back to the server (since the "password_ok=1" response is easy to forge).

 

Browser and plugin coding errors

Java Script provides an interface to a wide range of browser capabilities, some of which may have flaws such as buffer overflows. These flaws can allow attackers to write scripts which would run any code they wish on the user's system.

 

These flaws have affected major browsers including Firefox, Internet Explorer, and Safari.

 

Plugins, such as video players, Macromedia Flash, and the wide range of ActiveX controls enabled by default in Microsoft Internet Explorer, may also have flaws exploitable via Java Script, and have in the past. In Windows Vista, Microsoft has attempted to contain the risks of bugs such as buffer overflows by running the Internet Explorer process with limited privileges.

 

 

Sandbox implementation errors

Web browsers are capable of running Java Script outside of the sandbox, with the privileges necessary to, for example, create or delete files. Of course, such privileges aren't meant to be granted to code from the Web.

 

Incorrectly granting privileges to Java Script from the Web has played a role in vulnerabilities in both Internet Explorer and Firefox. In Windows XP Service Pack 2, Microsoft tightened the rules on what Java Script would be run with high privileges by Internet Explorer.

 

Some versions of Microsoft Windows allow Java Script stored on a computer's hard drive to run as a general-purpose, non-sandboxed program. This makes Java Script (like VBScript) a theoretically viable vector for a Trojan horse, although Java Script Trojan horses are uncommon in practice.

 

For More info:

 

== See also ==

 

 

External links

 

Comments (0)

You don't have permission to comment on this page.