PHP Security on i5/OS

PHP Security on i5/OS - Presentation Transcript

I5/OS Security in a PHP World Patrick Botz VP, Security Consulting Group8 Security, Inc. www.group8security.com

Agenda

What to Protect

Implementation

PHP Resources

Native Resources

How to Protect

Architecture

Web Server

PHP Core Components

Native Resources

IFS

i5/OS Security in a PHP World

What to Protect

Introduction

Information Assets == only valuable when:

used by authorized people

For authorized purposes

PHP == Another Great Way to Access Data on Your System

PHP also represents another “door” in the wall of the fortress

How are you going to protect that “door”?

How will you ensure that door cannot be used to access assets unrelated to those provided through that door?

Food For Thought

PHP is another interface to i5/OS – Just like ODBC, FTP, and Telnet are interfaces to i5/OS!

i5/OS resources need to be protected properly independent of PHP

No “exit points” for PHP

Limited capabilities do not apply!

Exclusionary Access Control (EAM) Required

Normal user profiles NOT allowed to access data directly

e.g. PUBLIC *EXCLUDE

i5/OS PHP architecture lends itself towards easy implementation in (EAM environment)

Notes

Native (i5/OS) Apache Web server

PASE-based (AIX) Components

Apache Web server

PHP Core

“ Integration” APIs i5os_*() db2_*() APIs

PHP admin tools for i5/OS

IFS

Native Database

What to Protect

ALL Information Assets on System!

Not just PHP resources

PHP Implementation (PHP components, directories, stream files, programs, libraries, objects, user profiles)

External Access Point(s)

Focus on Seams!!!

(i.e. white arrows)

From Whom to Protect

Bad Guys (gender neutral) on Internet

Bad Guys (gender neutral) on Intranet

Protecting the PHP Implementation/Environment

Notes

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.

After installing PHP, example HTML files, example PHP scripts and applications, configuration files, etc., are stored in one of two directories (or subdirectories thereof):

Zendcore /usr/local/zend /www.zendcore NOBODY NOGROUP ZENDADMIN ZENDTECH PHPWEBUSR PUBLIC *EXCLUDE Access Rights Execution Rights

User Profiles With Distribution

NOBODY PHP Apache Web server

ZEND core jobs (ZENDCOREAP)

Group = NOGROUP

Special authorities = *NONE

ZENDADMIN Start/stop jobs in ZEND subsystem

Pseudo number random generator for encryption related services

GROUP = *NONE

*ALL special authorities.

ZENDTECH Update PHP configuration

GROUP = *NONE

Special authorities = *NONE

NOGROUP Is a GROUP profile

Use this profile to grant access – not “NOBODY” user profile

NOTE: PASE UserIDs Equivalent to i5/OS User Profiles

User Profile to Consider

PHPWEBUSR

Configure native Apache Web server to run under a dedicated user profile

Special Authorities = *NONE

Group = *NONE

Zendcore /usr/local/zend /www/zendcore

/www/zendcore /www/zendcore/ *

Contains the i5/OS Web server configuration files and application resources.

Access Control Objective

PUBLIC *EXCLUDE

/www/zendcore

/www/zendcore/*

PUBLIC *X or *USE

/www

*EXCLUDE if no other web apps or other web apps permit

i5/OS Web server user profile may need *R (i.e. “r—”) to same directories

/usr/local/zend /usr/local/zend/ *

Contains the PHP Web server and PHP core config files and application resources.

Access Control Objective

Prevent anyone other than PHP administrators from accessing (not to mention changing) configuration files/resources

PUBLIC *EXCLUDE

/usr/local/zend

/usr/local/zend/*

PUBLIC *USE

/usr

/usr/local

ZENDCORE Library/Objects

Contains administrative tools/functions

Configure

Start/Stop

Access control objective

Prevent anyone other than PHP administrators from

Protect PROGRAMS that adopt QSECOFR

PUBLIC = *EXCLUDE

Consider using ZENDADMIN and ZENDTECH as group profiles

PHP administrator profiles should be a member of one or the other.

Notes

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.

Notes

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.

Configure Web Server Security

Web Server Security

Native I5/OS Web server acts as “mirror” for PHP Web server

Port 89

All requests to i5/OS server changed to requests to PHP server

All responses from PHP server changed to responses from i5/OS server

PHP Web server

Localhost (127.0.0.1)

Port 8000

Recommendations

Use reverse proxy in your DMZ

Buffer Overflow Considerations

Use SSL Connections

Run i5/OS Web server under “dedicated” user profile (e.g.. PHPWEBUSR)

Notes

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.

Programming Practices

i5_*() APIs

Connection management

Command calls *

Program calls *

Data retrieval *

Native file access *

System values *

Data areas

Print and working with spool files

Job logs

Active jobs

Object list

User space

Data queue

db2_*() APIs

Server/Connection

Result

Commit/Rollback

Fetch

Field Information

Key Information

Statement

Errors

Column/Procedure

Table Information

If you run with PUBLIC *USE or *ALL, you make it SIGNIFICANTLY easier for an internal or external attacker to directly and indirectly access sensitive data!

PHP Program File Management

Exclusionary access control only viable model!

PUBLIC = EXCLUDE, or

other = “---”

For everything related to PHP!

Give nobody or other service user profile read or write where necessary

Put PHP scripts/programs for separate functions in separate directories

E.g. /www/php/pgm1, /www/php/pgm2, /www/pgm3, /www/pgm/common

i5_connect() API.

resource i5_connect (string server, string user, string password[, array options]) .

Return Values :

i5/OS connection resource or false on failure.

Arguments :

server - Name of the server to connect to. Can be either a symbolic name or an IP.

Note: The system name can only be localhost or 127.0.0.1.

user - Username to use for connecting.

Note: If no user or password is provided, the connection will be established under NOBODY user profile.

Note: Username QSECOFR cannot be used in this function.

password - Password for the username

options – Miscellaneous connection options.

Change i5cmd process to run under supplied user profile for this connection

i5_adopt_authority() API

bool i5_adopt_authority (string username, string password, [resource connection]).

Return Values :

Boolean success value.

Arguments:

username - Name of the user to change to

password - Password for the user

connection - Connection - result of i5_connect

Protecting Database Files

db2_connect ("","","") Connects to the database on the PHP host system as user profile *NOBODY.

Note: When no userID/password provided, connection runs in the same process/job as PHP core!

Otherwise the connection runs in a separate pre-started job.

db2_connect ("* LOCAL "," SOMEUSER "," PASSWORD ") Connects to database on system on which PHP core engine is running as user profile SOMEUSER.

db2_connect (" 10.1.2.15 "," SOMEUSER "," PASSWORD ") Connects to remote database at 10.1.2.15 as user profile SOMEUSER.

db2_connect ("","","")

resource i5_connect (string server, string user, string password[, array options]) .

Return Values :

i5/OS connection resource or false on failure.

Arguments :

server - Name of the server to connect to. This can be either a symbolic name or an IP.

Note: The system name can only be localhost or 127.0.0.1.

user - Username to use for connecting.

Note: If no user or password is provided, the connection will be established under NOBODY user profile.

Note: Username QSECOFR cannot be used in this function.

password - Password for the username

options - Connection options

resource db2_exec ( resource connection, string statement [, array options]

Return values:

Statement resource if the SQL statement was issued successfully, or

FALSE if the database failed to execute the SQL statement.

Arguments:

connection A valid database connection resource variable as returned from db2_connect() or db2_pconnect() .

statement An SQL statement. The statement cannot contain any parameter markers.

options

Protect against SQL Injection Attacks!!!!!

Statement parameter – most important parameter to validate!!!! An SQL statement. The statement cannot contain any parameter markers.

Instead of db2_exec()

Use db2_prepare() with db2_bind_parm () and db2_execute()

db2_prepare() API

This API creates a prepared SQL statement which can include parameter markers (? characters).

resource db2_prepare ( resource connection , string statement [, array options ] )

Result value:

Returns a statement resource used as input to the db2_execute () and db2_bind_param () APIs.

Arguments:

Connection

A valid database connection resource variable as returned from db2_connect() or db2_pconnect() .

Statement

An SQL statement, optionally containing one or more parameter markers.

options

Parameter Validation

Do ROBUST parameter validation in your PHP code!

Parameter Validation Examples

A (very) Few Examples of Parameter Validation

Password variables

>= QPWDMINLEN

<= QPWDMAXLEN

UserID names

<= 10 characters

No special characters

SQL Search Text

Does not include ANY special characters or SQL operators

Parameter Validation Examples

A (very) Few Examples of Parameter Validation (cont.)

Miscellaneous variables

Reasonable lengths for pathnames

Reasonable parent directory pathnames for file specifications

Selected item from list is a member of selection list provided

Avoid text input fields when/wherever possible!

Use selection lists instead

Avoid asking end-user for userID/password

Run under NOBODY

Consider hardcoded userID and looking up password (VLDL entry?)

Notes

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.

Notes

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.

Summary

Summary

Like other external interfaces (e.g.. ODBC, FTP, Telnet, TFTP, etc.) to i5/OS, the PHP implementation and usage needs to be protected in order to protect:

Information resources associated with PHP applications

Information resources associated with other non-PHP applications on the same system

Protect

ZENDCORE Library

/www/zendcore

/usr/local/zend

PHP application directories

Use exclusionary access control model on your whole system

Use smart programming practices to prevent exposures

PHP Security for i5/OS

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.

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.