The PHPA does not currently have an official license to make it free. In addi- tion, the source code is not yet released; therefore, be aware of these facts, as they might (or might not) become a restriction for commercial use in the future. PHPA is currently available for Linux, FreeBSD, OpenBSD, BSDi, and Solaris. Zend Tools for optimization and caching opcode As the developer of the Zend opcode engine used in PHP, Zend has an edge over other open-source or commercial efforts in building PHP-friendly, high- performance tools. The commercial tools available from http://www.zend.com are often the current state-of-the-art in PHP and therefore worth a look if you have the budget for it. Summary In this chapter, you learned how to benchmark, stress-test, and improve your PHP applications for speed. You also learned how to buffer output, how to compress output, and how to cache output for faster response time. Finally, you learned about tools that can optimize PHP itself. 736 Part VI: Tuning and Securing PHP Applications 28 549669 ch21.qxd 4/4/03 9:27 AM Page 736 Chapter 22 Securing PHP Applications IN THIS CHAPTER ◆ Protecting your application-related files ◆ Controlling access to your applications ◆ Using MD5-based login ◆ Using MD5 encoding in your PHP application ◆ How to securely upload files ◆ Running PHP in safe mode THIS CHAPTER DISCUSSES A SET of security issues that you should know about when deploying your applications in the real world. Here I will discuss how you can con- trol access to your applications and related files, which is a big step in ensuring security. When you write applications there are various reasons for not allowing everyone access to your applications. This can be because of the fact that the appli- cation is needed for internal business or for external partners or customers or any- one. For example, a Web application that allows you to access your corporate e-mail from the Internet should have restricted access control vs. a Web application that allows potential customers to generate an automated quotation request or response for your products and services. This chapter will show you how to control access to applications that are not to be used by the masses but rather a defined set of users or systems. Controlling Access to Your PHP Applications When you deploy your application on the Web, it becomes available to everyone. Malicious hackers will try to find holes in your application to attack your data, your site, other sites, or all of the above. Therefore, you must take all the precau- tions necessary to ensure that all known risks are minimized or eliminated. This section describes how to control access to your application and related files using various Web server configurations. It is assumed that you are using Apache or an Apache-like Web server (such as Zeus). 737 29 549669 ch22.qxd 4/4/03 9:27 AM Page 737 Restricting access to your PHP application-related files When you create a large PHP application, many files might contain sensitive infor- mation. For example, the configuration files used in many of the applications in this book contain database connection information, paths, and so on, that are sen- sitive. You need to protect these files from visibility on the Web. You have two ways in which you can do so. Keep sensitive files outside your Web document tree This method requires that you keep your sensitive files in directories outside the Web directory tree and access them with explicit paths. For example: require_once ‘app_name.conf’; can be changed to require_once “/path/not/inside/docroot/app_name.conf”; Make it impossible to retrieve files with certain extensions If you are using Apache or an Apache-like Web server such as Zeus, you can restrict access to configuration files or any other files using Web server configura- tion directives. For example, if your Web site supports the use of .htaccess files that contain per-directory configuration information, you can create an .htaccess file in the top directory of your Web site as follows: # for .htaccess <Files “*.conf”> Order deny,allow Deny all </Files> This ensures that whenever your Apache server gets a request for a file that ends with a .conf extension, it denies access to that file. If you have access to the primary Apache server configuration file, httpd.conf, you can create a global con- figuration such as the following, which applies to all Web sites served by the Apache server: # for httpd.conf <Directory /> <Files “*.conf”> Order deny,allow Deny all </Files> </Directory> 738 Part VI: Tuning and Securing PHP Applications 29 549669 ch22.qxd 4/4/03 9:27 AM Page 738 This tells Apache that it cannot serve any files with .conf extensions from any directories within the Web document root (pointed to by the DocumentRoot directive). Using Web server–based authentication Often, you will find it necessary to restrict access to your Web applications. In such cases, you can use your Web server’s basic authentication scheme quite easily. For example, to require user authentication for an application stored in http://yours- erver/yourapp/ , you can create or edit the following .htaccess file in the %DocumentRoot%/yourapp directory: AuthType Basic AuthName “Restricted Access” AuthUserFile /path/to/yourapp.users Require valid-user You can also put the preceding configuration in your httpd.conf file using a Location container, as shown here: <Location “/your_app/”> AuthType Basic AuthName “Restricted Access” AuthUserFile /path/to/yourapp.users Require valid-user </Location> Don’t forget to change your_app and /path/to/yourapp.users with the appropri- ate directory and file names. Once you have created this configuration, you need to use Apache’s htpasswd utility to create users. For example, to create a user called joegunchy, you can run the following: htpasswd -c /path/to/yourapp.users joegunchy If htpasswd is not in your path, you need to provide the path name. For exam- ple, if you store htpasswd in /usr/local/apache/bin, you can run the following: /usr/local/apache/bin/htpasswd -c /path/to/yourapp.users joegunchy Creating a subsequent user does not require the -c option. Use this option only for the first user.In addition,make sure that the /path/to/yourapp.users file is accessible by the Apache Web server. Chapter 22: Securing PHP Applications 739 29 549669 ch22.qxd 4/4/03 9:28 AM Page 739 When creating a user, you will be asked to enter a new password for the user. Enter the desired password and try to access your application via http://yours- erver/yourapp/ . You will be promoted for a username and password. Use the newly created username and password to log in and access your application. If you need to know the username in your PHP application, use the $_SERVER[‘REMOTE_USER’] value, as shown in the following example: <?php $thisUser = $_SERVER[‘REMOTE_USER’]; if (empty($thisUser)) { // Your Web server authentication is // not working. exit; } echo “Hello $thisUser”; ?> When this script is accessed from a Web server–authenticated directory, the script will contain the username that successfully logged in. You can also use $_SERVER[‘PHP_AUTH_USER’] in place of $_SERVER[‘REMOTE_USER’]. One of the problems with Web server authentication is that you have no way to log out the user by force. The Web browser always resends the authenti- cation credentials (username/password) upon each request, and therefore the Web server keeps re-authenticating the user.If you need to allow logout, you should use application-level authentication, as discussed in Chapters 4 and 5 of this book. Using the MD5 message digest for login When you use a Web-based login form to log in a user, the username and password are transmitted as plain text. This is a major weakness if high security is desired. Unfortunately, because PHP cannot be implemented on the client side, there is no PHP solution that you can use to turn the plain-text data into encrypted or encoded form. The best alternative for a high-grade Web login solution is to use a Secure Socket Layer (SSL)-based Web server, which encrypts all communication between the client and the server. In the absence of that, you can consider the following solution. 740 Part VI: Tuning and Securing PHP Applications 29 549669 ch22.qxd 4/4/03 9:28 AM Page 740 . learned about tools that can optimize PHP itself. 736 Part VI: Tuning and Securing PHP Applications 28 549669 ch21.qxd 4/4/03 9:27 AM Page 736 Chapter 22 Securing PHP Applications IN THIS CHAPTER ◆ Protecting. applications ◆ Using MD5-based login ◆ Using MD5 encoding in your PHP application ◆ How to securely upload files ◆ Running PHP in safe mode THIS CHAPTER DISCUSSES A SET of security issues that. the future. PHPA is currently available for Linux, FreeBSD, OpenBSD, BSDi, and Solaris. Zend Tools for optimization and caching opcode As the developer of the Zend opcode engine used in PHP, Zend