PHP is rapidly becoming - if not already - the defacto-standard for Web application development and deployment. Writing PHP applications that accurately enforce your security policies requires knowledge of the general architecture of PHP as well as the i5/OS specific components of the architecture.

Sensitive resources include HTML files, PHP scripts/programs, configuration files, as well as the native data and program resources. Typically HTML and PHP resources along with configuration files for most Web related applications reside somewhere in the “root” file system (i.e. “/”) accessed through IFS.

These resources must be protected in order to protect other sensitive resources on your system. If an attacker can change one or more of the various configuration files, they can potentially change or remove security controls intended to prevent access to certain resources via PHP.

The user profile under which the i5/OS Web server runs needs search authority to “/www”, “/www/zendocre”, and subdirectories thereof. The same user profile needs *USE (or *R authority, or “r--“ authority in POSIX terminology) to files in these directories. By default the i5/OS Web server is configured to run under the QTMHHTTP user profile. To protect these resources we recommend:

Ensure PUBLIC *EXCLUDE (i.e. “other = ---“ in POSIX terminology) to “/www” and “/www/zendcore” and everything underneath this directory.

Change the default configuration to run under a user profile specific for the i5/OS Web server front-ending the PHP Web server (e.g.. “I5OSPHPPRF”). Doing so prevents access using the new user profile to any other i5/OS Web server configurations that may be in use on the system.

Ensure PUBLIC *EXLUDE to the “zend” directory and everything underneath.

NOBODY needs the same authority to items in this directory path that QTMHHTTP (or a user profile of your choice) needs to items in the “/www/zendcore” path. Making “NOGROUP” the primary group for everything in the PHP related directories is one way to accomplish this. This can be easily done by using the CHGPGP command or the “chgrp” POSIX command in PASE or QSH.

Grant “NOGROUP” group profile authority of *X (i.e. “—x” in POSIX terminology) to directories in the “/www/zendcore” and “/usr/local/zend” directory path (including subdirectories). *X represents search authority when granted to a directory. Search authority on a directory allows a profile to “use” contents of the directory, but not to discover (or list) the contents of the directory. Use the CHGAUT or “chown” POSIX command in PASE or QSH to accomplish this.

Grant “NOBODY” group profile *USE (or *USE) authority to files located in “/www/zendcore” and “/usr/local/zend” directories and subdirectories.

A native library, ZENDCORE is also created when PHP is installed. This library contains utility programs and service programs for managing PHP. Ensure that PUBLIC authority to the library and its contents are *EXCLUDE. Restrict access to this library to a small number of highly trusted administrators or operators.

The PHP Web server only accepts requests from the localhost address (127.0.0.1) on port 8000. The i5/OS Web server acts as a sort of reverse proxy for the PHP Web server – as a mirror really. It listens on port 89. The ProxyPass directive causes all requests to the i5/OS Web server to be forwarded to http://127.0.0.1:8000 using the same URL. The ProxyPassReverse directive changes response headers returned to the caller back to the original server name before returning results; thus hiding the ‘two server” architecture. However, since both the i5/OS and PHP Web servers run on the same system, the usual security benefits of a reverse proxy (e.g.. hiding internal network addresses and ports, etc.) aren’t realized fully.

To provide the full security value of a reverse proxy, run a reverse proxy in your DMZ and access the i5/OS PHP implementation -- located behind your firewall -- through it. Doing this prevents direct external access to your entire i5/OS PHP implementation.

You can reduce the potential of a successful buffer overflow attack mounted externally against your implementation. Use a separate Web server (or instance) for non-PHP related applications. Configure the reverse proxy in the DMZ to send requests for PHP related URLs to the front-end i5/OS Web server on the system hosting PHP. The DMZ Web server should send requests for non-PHP related URLs or applications to a separate i5/OS Web server. These changes make it more difficult for attackers to blindly mount buffer overflow attacks against the PHP Web server using arbitrary URLs. The attacker will have to use URLs for specific PHP applications.

Consider using a separate user profile under which to run the i5/OS Web server. This is an especially good idea if you host other i5/OS Web server instances on the same machine. Mistakes in security configuration for any of the i5/OS Web server instances are much less likely to result in exposures to your PHP configuration or applications.

I5_OS() APIs can only be used to access i5/OS resources on the same system as the PHP core engine. All of the functions are implemented in native i5/OS program, i5_COMD (see item 8 in the chart above), provided with the PHP installation. The PHP core engine runs in PASE. It interprets the toolkit APIs coded in a PHP application and sends requests to the i5_COMD job which listens on port 6067.

Before using any other i5_*() API, you must first establish a connection to i5/OS. This is done through the i5_connect() API which is discussed in more detail below. Once a connection is established, a PHP application can call commands, programs, service programs, and access many of types of native system objects. If you don’t have the appropriate object level access control in place, only the logic added to PHP applications by programmers stand between your sensitive data and security exposures. It is possible, using the PHP/Java Bridge to use the i5/OS Java toolkit to access i5/OS resources on either local or remote systems. It provides full access to nearly all i5/OS resources. Security details are beyond the scope of this document.

Much of the “General Programming Tips” section pertains to this API or the construction of the statement input parameter. If you construct this parameter using PHP variables containing user provided input, this API becomes one of the more common security exposures.

In addition to the tips provided above, consider calling db2_prepare() to prepare an SQL statement with parameter markers for input values. Prepared statements are executed by the db2_execute() to pass in the input values and avoid SQL injection attacks.

When you prepare a statement, you can include parameter markers for input values. When you execute a prepared statement with input values for placeholders, the database server checks each input value to ensure that the type matches the column definition or parameter definition. This removes the onus of total responsibility for parameter checking from the programmer. Use db2_prepare () and db2_execute () rather than db2_exec () wherever and whenever possible.

Trademark & Disclosure Statements The following terms and marks are trademarks of Group8 Security, Inc.: Security=f(cost,risk) Managing the Security Equation Helping Business Manage the Security Equation Other company, brand and product names are trademarks or registered trademarks of their respective holders. Information is provided “AS IS” without warranty of any kind. All examples described are presented as illustrations of how customers have used Group8 recommendations, products or services and are the results they may have achieved. Actual results may vary by customer. Information concerning non-Group8 products or services was obtained from a supplier of these products, published announcement materials, or other publicly available sources and does not constitute an endorsement of such products by Group8. Group8 Security, Inc. is an independent company. It does not receive or accept any form of payment for recommending other company’s products. We recommend products of which we are aware and with which we have at least some understanding or experience. We encourage Customers to conduct their own product evaluations and select a product they believe will meet their requirements. Copyright Group8 Security, Inc. 2007-2008. All rights reserved.

45.
ABOUT GROUP8 SECURITY: At Group8, we believe that IT security is first and foremost a business issue. It has technical aspects but is not inherently a technical problem. Security is something a company does, not something they have or can buy. Our mission is to partner with you to help define, implement, and manage your security. We'll do this by helping you establish and manage business processes that lead to sound IT security business decisions. Together we'll define security objectives in terms of business requirements, and make technical decisions based on costs and return on investment as well as the effectiveness of the technical measures employed to enforce business objectives. Group8 Security, Inc. 4790 Caughlin Pkwy, Suite 398 Reno, NV 89519-0907 Tel: 775-852-8887 www.group8security.com ABOUT THE SPEAKER: Pat Botz heads up security consulting for Group8, bringing his extensive experience in system security planning to our customers. Prior to joining Group8, Pat served as the Lead Security Architect and Team Leader for the IBM, working on some of the most widely used midrange servers is the business world with a focus on authentication, authorization, auditing, and ease of use. Following his work on System i and the IBM Virtualization Engine, Pat founded the IBM Lab Services security consulting practice with a primary focus on helping customers meet various industry regulations such as SOX, PCI DSS, and SAS 70. He additionally worked to help customers improve the effectiveness and efficiency of their current security management processes, assisting them with moving to exclusionary access control models, eliminating passwords in various environments, managing User IDs, implementing encryption, and auditing on various platforms. Pat is co-author of the book /Expert’s Guide to OS/400 and i5/OS Security/, and has published numerous articles in the trade press and IBM magazines. He is also a noted worldwide security conference speaker, presenting at various conferences and in webcasts including COMMON, IBM Technical Conference, various user groups, St. Cloud State University Security conference, and IBM Business Partner conferences.