Some of the concerns are discussed in the notes below.

• Whatever scripts are run will be executed with the privilege set of the web server (or virtual host), which may be more powerful than the set of privileges we had intended to give an individual web user.

  For example if we run a program with high priviledges, and allow other users to connect to it and (potentially) issue commands through it then we are effectively giving them higher privileges, and need to ensure that cannot be abused.

• Similarly, such scripts may also be accessible to local users of the system, e.g. on a linux box anyone who is able to locate the script in the file system might be able to execute the script independent of the browser/server environment.

  This also means that if our scripts store passwords or the locations of other scripts and executables then the local users can read those passwords and script locations (at least if the scripts are written in languages such as Perl and Python).

  Since many scripts establish connections to other servers (e.g. database servers), a user who can run the script might also be able to use this as a means of obtaining access to those other servers.

  Always be very cautious about who can access files and scripts, both locally (i.e. people with their own accounts on the server) and remotely (via browsers or through external scripts and applications). If you make use of included files with connection/password information, be sure they are stored outside the regular web tree and are not named something obvious. As a general guard against snooping, it is also advisable to ensure that every directory in your web tree includes an index file. This ensures that no snooper ever sees the raw listing of a directory's contents.

• If data is being submitted to a script through forms, the data submitted is not guaranteed to have the format we expect.

  This is particularly dangerous if we take the submitted data as text and attempt to embed it in a command to be run by the script.

  For instance, suppose we want to allow the user to look up the size of a file, and once they give us the filename we will embed that in a linux "wc" command to count the number of bytes in the file:

      // no particular language is assumed here,
      //    the syntax will vary but the problem 
      //    is common to most scripting languages
      cmdstr = "wc -c " + filename;
      execute(cmdstr);
  

  Now suppose an unscrupulous user enters the following into the filename field: "somefile ; rm -r *"

  When we go to execute the command string it actually runs two commands: "wc -c somefile" and "rm -r *"

• Even if we expect the data for our script to come from a particular form, if a user knows the location and name of the script there is nothing to stop them from creating their own form (or program) to submit data to our script, and thus what they submit may have a completely different set of field names and data values than those we were expecting.

  This means that, even if we use something like a set of javascript commands to perform error-checking on data fields before a form is submitted, there is still no guarantee that our script can trust any data values it receives (since we can't guarantee that the source of the request went through our error checking).

  Our scripts should always check the identifiers in a submission match those that we were expecting, and that the data types match those that we were expecting, and that user submitted text does not contain special characters or escape sequences that might allow the execution of commands, and that any actual text strings submitted contain only data strings that conform to our acceptable entries.

• Suppose we allow a user complete freedom to pick their own username, and somewhere on a web page we display their username as is.

  An unscrupulous user enters the following as their chosen username:
  Blahblah<script language="javascript" src="SOMEURL"> </script>

  Conceivably, this can allow the loading of unintended javascript code when the username is displayed!

  The moral: be picky about what characters are permitted in usernames, and limit the length of usernames.

• File and data field sizes can also be a concern. If a user is allowed to upload files or enter information, then we must ensure we always check and limit the size of the file or the data that they enter. Many exploits and attacks are based on the idea of hitting a program with values that are larger than it is designed to process.

• Cookies are a popular technique for storing information relevant to a website (userid, preferences, authentication information, etc) on the client's machine. There are two major security issues related to cookies: (1) many browsers store them as plain text somewhere on the user machine, (2) they are basically sent in plain text (unless you are using https or something similar. In either case, you have to be very careful about the kind of data you store in cookies, how you use them, and how much you trust them.

• Suppose we store usernames and passwords in a database, and have a user enter their name and password into a form. We then glue the values they entered into an SQL query, e.g.:

  // username and password have been POSTed to the script
  $username = $_POST['username'];
  $pwd = $_POST['password'];
  $query = "SELECT user, password FROM pwdtable WHERE user='".$username."'and password='".$pwd."'";
  $result = mysql_query($query);
  

  If the user is feeling particularly malicious, they can enter SQL snippets for the username, e.g. ' OR 1=1 #
  In such a case, the $query variable would now contain
  SELECT user, password FROM pwdtable WHERE user='' OR 1=1 # and password=''
  This always evaluates to true (because of the OR) and comments out the password requirement!

  One solution: before including the user data in our query, we'll trim it, and add slashes to deal with any ' characters in the user data, e.g.:

  $username = addslashes(trim($_POST['username']));
  $pwd = addslashes(trim($_POST['password']));