Jump to content - Jump to section navigation
This document details the security criteria that a web application must meet to receive support from LTS. All internal LTS applications should meet this standard, as should any application that will be hosted on LTS servers other than people.brandeis.edu.
All user input must be fully validated. User input includes form GET and POST variables as well as cookies. Validation must strictly define valid input and deny anything else. For example, "between 4 and 8 numeric characters," and "between 0 and 64 characters of letters, numbers and spaces" are both good input descriptions, but "must contain an at sign and end in dot com" is not. The validation must be done by the CGI application itself and NOT by Javascript code.
Applications must follow the principle of least privilege, meaning that they have access to do only what they need to. For example, if an application only retrieves information from one table in one database, it must only have SELECT access, and only to that particular table.
If the application stores user password information, it must do so as a salted, cryptographically secure hash. MD5-based UNIX crypt() is an example of an acceptable hash, while DES crypt() and and any unsalted hashes are unacceptable.
If the application needs a username and/or password to log into some other service as part of its function (database connection, XML-RPC, etc.), those credentials should not be stored in the same file as the program source code. For example, if the application is a Perl script, usernames and passwords should not be stored in the main .pl file.
Credentials should instead be stored in a seperate file which is located outside the web server's document storage directory. For example, a PHP script running out of the file /usr/local/apache/htdocs/script.php on a UNIX machine might store its password information in the file /etc/php/script-credentials.
Wherever possible, the application should use Cosign single-sign on rather than implementing its own authentication system.
Applications must not rely on "security through obscurity," or the use of information which, if known, would compromise security. For example, it is unacceptable for there to exist a particular "secret" URL which allows a user to bypass the login system. Valid login credentials such a usernames and passwords are a necessary exception to this rule.
Applications should not execute OS shell commands, and especially not pass user input to the shell. Functions which execute shell commands are frequently called things like system(), exec(), etc.
Applications should not write to the filesystem. If an application needs to store persistent state information, it should use a backend database.
