原始连接：
http://www.owasp.org/index.php/PHP_Top_5
PHP is a very popular language with many flawed security "features". Every PHP developer and hoster should understand the primary attack vectors being used by attackers against PHP applications.
This article is the underlying research behind the SANS Top 20 2005's PHP section. The methodology used in the preparation of this article is to review all Bugtraq postings containing the word "PHP" and categorize each unique flaw. The author analyzed the most popular flaws / attacks, and researched prevention techniques, resulting in this article.
If you need more information on how to write solid, secure PHP, please consult the references.
Contents [hide]
1 Special notes for this edition
1.1 About "safe_mode"
1.2 addslashes() / magic_quotes
2 P1: Remote Code Execution
2.1 Description
2.2 Operating Systems Affected
2.3 CVE/CAN Entries
2.4 How to Determine if you are Vulnerable
2.5 How to Protect Against It
2.6 References
3 P2: Cross-site scripting
3.1 Description
3.2 Operating Systems Affected
3.3 CVE/CAN Entries
3.4 How to Determine if you are Vulnerable
3.5 How to Protect Against It
3.6 References
4 P3: SQL Injection
4.1 Description
4.2 Operating Systems Affected
4.3 CVE/CAN Entries
4.4 How to Determine if you are Vulnerable
4.5 How to Protect Against It
4.6 References
5 P4: PHP Configuration
5.1 Description
5.2 Operating Systems Affected
5.3 CVE/CAN Entries
5.4 How to Determine if you are Vulnerable
5.5 How to Protect Against It
5.6 References
6 P5: File system attacks
6.1 Description
6.2 Operating Systems Affected
6.3 CVE/CAN Entries
6.4 How to Determine if you are Vulnerable
6.5 How to Protect Against It
6.6 References
[edit]Special notes for this edition
[edit]About "safe_mode"
Safe Mode implemented without design or thought is simply not safe. It cannot be made to be safe, and does not add any actual safety. Most of the restrictions implemented by safe mode can be worked around by clever hacks. These have been extensively used by software which needs to get around the safe_mode restrictions to operate, and many PHP attacks which seem to bypass it like a hot knife running through butter.
Hosters, do not just switch safe_mode on and lock it down hard. Such controls rarely work as expected, and more to the point it does not prevent any of the five major attack vectors presented in this paper. Only code reviews and ensuring that code is tested for security flaws can the risk of attack be reduced.
This is not to say that safe_mode is useless. Well designed software can use thoughtfully chosen safe_mode restrictions to improve defense in depth. Such software should be given that opportunity by using .htaccess (or similar mechanisms) to selectively enable safe_mode restrictions as they need.
[edit]addslashes() / magic_quotes
An earlier version of this article recommended the use of addslashes(). In general, this is poor advice today, particularly when PHP is coupled with the most popular open source database, MySQL.
To prevent SQL injections, it is essential that:
magic_quotes_gpc is disabled in all PHP installations
addslashes() should be deprecated - it does not protect against SQL injections
Software should move post-haste to support safe(r) database access mechanisms, such as PDO
The latter requires hosters to upgrade their PHP to the latest PHP 5.1. Unfortunately, there has been low take up of the safer versions of PHP due to perceived incompatibilities with much of the PHP software base. Software which is incompatible with PHP 5.x is simply insecure, and should not be run. It is our opinion that PHP 4 is unsecurable as it does not possess PDO and a number of other safer interfaces. PHP 4.x should not be run in any shared or dedicated environment of any consequence. Hosters should give notice to their clients that they have only a short time to bring their software up to date with PHP 5.x and rapidly adopt the latest version of PHP.
[edit]P1: Remote Code Execution
[edit]Description
The most widespread PHP security issue since July 2004 is remote code execution, mostly via file system calls.
The root causes of this issue are:
Insufficient validation of user input prior to dynamic file system calls, such as require or include or fopen()
allow_url_fopen and PHP wrappers allow this behavior by default, which is unnecessary for most applications
Poor permissions and planning by many hosters allowing excessive default privileges and wide ranging access to what should be off limits areas.
From PHP 4.0.4 onwards, allow_url_fopen was enabled by default, making poorly written applications vulnerable through no changes of their own. As of PHP 4.3.4, the PHP project changed the access on this feature to PHP_INI_SYSTEM, which prevents code from easily disabling this feature via the use of ini_set(). This has the unfortunate effect that only hosters can change this setting, many of whom cannot make wholesale changes to php.ini without breaking their customers code, including well-written code which relies upon these features.
[edit]Operating Systems Affected
PHP 4 (after PHP 4.0.4), 5.x
[edit]CVE/CAN Entries
There are more than 100 such vulnerabilities reported since July 30, 2004. These are a representative sample:
phpBB Remote Code Execution Vulnerability
http://www.securityfocus.com/bid/14086
TikiWiki Remote Code Execution Vulnerabilities
http://www.securityfocus.com/bid/12328
XML-RPC Remote Code Execution (many vendors)
http://www.securityfocus.com/bid/14088
[edit]How to Determine if you are Vulnerable
Inspect your code for constructs like:
$report = $_POST[‘report_name’];
include $report;
or
$username = $_POST[‘username’];
eval(“echo $username”);
The above snippets are not exhaustive. Other code constructs to look for include:
fopen(), fsockopen()
Direct command execution - popen(), system(), ` (backtick operator). Allows remote attackers to execute code on the system without necessarily introducing remote code.
Direct PHP code execution via eval()
Limited evaluation if the attacker supplied PHP code is then used within double quotes in the application code – most useful as an information disclosure
include, include_once, require, require_once with dynamic inputs
file_get_contents()
imagecreatefromXXX()
mkdir(), unlink() and rmdir() and so on - PHP 5.0 and later has limited support for some URL wrappers for almost all file functions
[edit]How to Protect Against It
Developers should
Review existing code for file operations, include/require, and eval() statements to ensure that user input is properly validated prior to first use
When writing new code, try to limit the use of dynamic inputs from users to vulnerable functions either directly or via wrappers
Hosters should:
Disable allow_url_fopen in php.ini by setting it to 0
Enable safe_mode and set open_basedir restrictions (if you know what you're doing - it's not really that safe!)
Lockdown the server environment to prevent the server from making new outbound requests
OWASP calls on the PHP Project to by default disable remote file support and associated wrappers, and allow applications that require these features to selectively enable them on a per application basis.
[edit]References
http://php.net/features.safe-mode
http://php.net/features.remote-files.php
Shiflett, C., Essential PHP Security,
