On the Security of PHP, Part 2

We conclude our look at securing PHP code with some advice on programming guidelines, user-input filtering, and configuration settings. Upon finishing this lesson, you should be alert to the major liabilities of working with PHP.

provided by: 
Originally published at Internet.com


Review Part 1.

Secure Programming Guidelines



The way to secure PHP scripts is through a carefully selected combination of configuration settings and safe programming practices. Based on the vulnerabilities that we have studied so far, we will now set forth to establish some rules that can help avoid dangerous situations.

Using PHP Safe Mode



PHP can be set up so that it executes scripts in a restricted environment to decrease the amount of damage that can be inflicted by insecure programs. This modus operandi is called "safe mode". The configuration directive safe_mode in php.ini turns safe mode on and off. The safe_mode_exec_dir directive specifies a directory from which scripts can be loaded. PHP will not execute a script if it is not in this directory. Furthermore, PHP will not let a script call another program that is not in this directory. This way, even if there is a security hole in the script that allows attackers to run arbitrary commands on the script, they will be limited to whatever is in the safe mode executable directory. As a general rule, if it is not absolutely necessary for scripts to be able to alter a variable, protect it.

To prevent tampering with environment variables, PHP safe mode makes use of another php.ini configuration setting that restricts the user's ability to modify them. The field safe_mode_allowed_env_vars contains a list of prefixes that identify the names of the environment variables the user is allowed to change. Thus, any environment variable whose name begins with something not listed in safe_mode_allowed_env_vars cannot be altered from within a PHP script. The default list consists of the prefix "PHP_" only. As we have seen, some of the PHP_ variables also contain sensitive information, so this restriction does not always solve the problem completely...

Read article at Internet.com site
Related Articles
- Introduction to Input Validation with Perl
How can we make software that withstands malicious input attacks? We can start by minimizing the set of entities our software trusts and by conscientiously validating all input - then "hope for the best."
- ASP Example 2: Password Protection
- JavaScript Security
- DHTML Example #8- Toggling with Netscape
- Security Issues in Perl Scripts: Perl Taint Mode
- CGI
- On the Security of PHP, Part 1
- So, You Want to Layer, Huh? Part II
- Security Issues in Perl Scripts
- Password Protection
Regional Articles
- On the Security of PHP, Part 2 Alabama
- On the Security of PHP, Part 2 Alaska
- On the Security of PHP, Part 2 Arizona
- On the Security of PHP, Part 2 Arkansas
- On the Security of PHP, Part 2 California
- On the Security of PHP, Part 2 Colorado
- On the Security of PHP, Part 2 Connecticut
- On the Security of PHP, Part 2 DC
- On the Security of PHP, Part 2 Delaware
- On the Security of PHP, Part 2 Florida
- On the Security of PHP, Part 2 Georgia
- On the Security of PHP, Part 2 Hawaii
- On the Security of PHP, Part 2 Idaho
- On the Security of PHP, Part 2 Illinois
- On the Security of PHP, Part 2 Indiana
- On the Security of PHP, Part 2 Iowa
- On the Security of PHP, Part 2 Kansas
- On the Security of PHP, Part 2 Kentucky
- On the Security of PHP, Part 2 Louisiana
- On the Security of PHP, Part 2 Maine
- On the Security of PHP, Part 2 Maryland
- On the Security of PHP, Part 2 Massachusetts
- On the Security of PHP, Part 2 Michigan
- On the Security of PHP, Part 2 Minnesota
- On the Security of PHP, Part 2 Mississippi
- On the Security of PHP, Part 2 Missouri
- On the Security of PHP, Part 2 Montana
- On the Security of PHP, Part 2 Nebraska
- On the Security of PHP, Part 2 Nevada
- On the Security of PHP, Part 2 New Hampshire
- On the Security of PHP, Part 2 New Jersey
- On the Security of PHP, Part 2 New Mexico
- On the Security of PHP, Part 2 New York
- On the Security of PHP, Part 2 North Carolina
- On the Security of PHP, Part 2 North Dakota
- On the Security of PHP, Part 2 Ohio
- On the Security of PHP, Part 2 Oklahoma
- On the Security of PHP, Part 2 Oregon
- On the Security of PHP, Part 2 Pennsylvania
- On the Security of PHP, Part 2 Rhode Island
- On the Security of PHP, Part 2 South Carolina
- On the Security of PHP, Part 2 South Dakota
- On the Security of PHP, Part 2 Tennessee
- On the Security of PHP, Part 2 Texas
- On the Security of PHP, Part 2 Utah
- On the Security of PHP, Part 2 Vermont
- On the Security of PHP, Part 2 Virginia
- On the Security of PHP, Part 2 Washington
- On the Security of PHP, Part 2 West Virginia
- On the Security of PHP, Part 2 Wisconsin
- On the Security of PHP, Part 2 Wyoming

Rss   Delicious   Digg   Add To My Yahoo   Add To My Google   Bookmark   Search Plugin

Topics:
Architecture & Design Languages & Tools Project Management Web Services
Database Microsoft & .NET Security Wireless
Java Open Source Techniques XML