For Webmasters, there are a few JavaScript issues that create problems on the web site's computer.
Standalone JavaScript scripts require an interpreter. If that standalone script is used as a CGI program, the interpreter is typically stored with the web server. By convention, a directory called cgi-bin is used. However, on Window NT, this exposes the interpreter to the web user's control—they can submit URLs that have attached script commands, which are then executed by the interpreter. Such commands could read or delete files, or cause other similar problems. Put the interpreter elsewhere for Windows NT web sites.
Chapter 2 has an example of how a ScriptEase 4.0 JavaScript interpreter can be controlled via command line arguments.
An issue affecting both server-side JavaScript and standalone JavaScript in CGI programs relates to form submissions. Forms are submitted from web browsers, and without security agreements, the data in a web browser is insecure. An HTML form which submits to a web server can be pulled apart by a hostile user (maybe it's a tax form), mimicked or rewritten in another page and submitted from that page. If the form is normally subject to complex JavaScript validation, all that validation can be ripped out by the hostile user and data submitted that would otherwise be stopped by validation. Alternatively, the user could write a different form that submits to the same CGI program.
Therefore, the receiving JavaScript can't assume the form data is in good order, just because some users have proper client-side JavaScript validation in place. Making this assumption when it's not true can result in the CGI program failing.
If the submitting user is not trustworthy, as on the public Internet, then all the submitted form data should be thoroughly checked in the server-side JavaScript or CGI program to avoid surprises. Relying on client-side JavaScript only works in a secure environment such as a corporate Intranet.
This trivial example illustrates why any kind of assumption about public form data is bad. This is the original:
<HTML><BODY><FORM ACTION="update.cgi">
Enter account balance:
<INPUT TYPE="text" ONCHANGE="if (!parseInt(this.value)) this.value='NO-BALANCE';">
<INPUT TYPE="submit">
</FORM></BODY></HTML>This is a copy hacked by a hostile user:
<HTML><BODY><FORM ACTION="update.cgi">
Enter account balance:
<INPUT TYPE="text">
<INPUT TYPE="submit">
</FORM></BODY></HTML>
In the first case, the form will always submit a valid, numeric balance, or else the special string "NO-BALANCE". It might therefore seem reasonable for the 'update.cgi' program to expect only these values. However, the hacked copy submits to exactly the same CGI program, and can accept any string, including negative numbers and random garbage. Therefore the CGI program cannot afford to trust the client-side JavaScript in an insecure public arena.
Because of the trap with form submissions, data supplied by the user is highly suspect and should be checked thoroughly. Use of eval() in web server JavaScript should be examined very carefully if the argument passed to this method comes from the user, or else unexpected statements might be run. Standalone JavaScript that supports functions like system() or popen() calls are equally cause for concern, because the user data used as arguments to these functions might cause unexpected programs to run..