ZendCon Session Notes - Securing PHP Applications
This session, presented by Ilia Alshanetsky, covered the most common PHP security mistakes, as found by searches on Google Code Search.

You can get the specific search terms and examples from Ilia's website once he gets the conference slides online, but this is a quick run-down of the issues:

Cross-Site Scripting (XSS)
User supplied HTML is displated as-is to the screen.
Over 90,000 results from Google code search, with specific examples from phpMyAdmin, phpMyEdit, University of Toronto, and Modernbill.

Possible exploits with this class include cookie/session theft, content modification, cross-site request forgery initiation, and social engineering (by displaying a real site's content or forms).

Preventing this involves passing input through htmlspecialchars() or htmlentities(), or to use the filter extension to santize input (new in PHP 5.2).

SQL Injection
User-supplied input used as-is in SQL queries.
Over 3,000 results, with examples includign Bugs (a bug tracking system), OSTicket, XOOPS, and phpMyAdmin.

Possible exploits include arbitrary query injection, arbitrary data retrieval, denial of service (esp. with (BENCHMARK(very-large-number, ...)), and data modification. Ilia's examples used subqueries, which I hadn't previously considered, but which are still quite effective.

Solutions include using prepared statements; some some databases can even reject queries if the data types don't match between the query and the table columns. Note that string escaping functions don't work for multibyte charater sets, as it's often possible to craft an invalid sequence in a multibyte character set that can cause the escaping functions to not work as intended.

Code Injection
User can make script execute arbitrary PHP Code.
Thousands of results (but a number of these are false positives?). Specific examples include Serendipity, WordPress, YaBB, abd Squirrelmail Plugin.

Possible exploits include sensitive file retrieval (e.g. including ../../../../../etc/passwd), arbitrary code execution, or content removal.

One should never pass user input to include(), require(), or eval() (and also, the shell functions, such as system(), exec(), shell_exec()). If it's necessary to do so, one should build a whitelist of acceptable values, and even obfuscate them in some way with a lookup table so that the user input is not directly what is on the filesystem. Ilia also gave a number of solutions that apply to hosting company setups to help mitigate the problem.

Header Injection
Gives hacker the ability to inject arbitrary content headers.
Over 8,000 results, with examples including Cacti, TikiWiki, Horde, and phpMyConference.

Possible exploits include cache poisoning (which is an especially bad problem if proxy servers are involved), arbitrary url redirection (including circular redirects, which can act as a DoS), and cookie overload/session fixation.

Solutions include using PHP 4.4.2 or 5.1.2 or later, where header() will only emit a single header line at a time. Also, avoid passing user input to header(), setcookie() or session_id(), and/or pass user input through urlencode().

Session Fxation
Hacker can hardcode user's session id to a known value.

if an attacker can get the user to log into a site with a session id specified, the hacker can then try the url later, gaining access if the user is still logged in.

A solution to this is to use session_regenerate_id(), which changes the user's session id. Ilia says this normally only needs to be done at privilege escalation (e.g. when the user logs in, or accesses certion functions), but says that some people use it on every request.

Information Disclosure
Sensitive information is exposed to unauthorized users.

Ilia's specific examples here centered around leaving error messages enabled on production sites. This can result in disclosing the filesystem paths of PHP files, which provide attackers with information that may make subsequent attacks easier. In older versions of PHP, creative exploitation of error output could also lead to XSS. And some functions may expose sensitive parameters as part of the error message. (In particular, one credit card processing extension is known to emit usernames and paswords as part of error messages.)

Arbitrary File Output
Usually caused by a function such as fopen() using user input to identify which file to open.

This seems to be a fairly uncommon attack. Solutions include using open_basedir, disallowing allow_url_fopen, and preventing the web server to access itself via firewall rules.

There's also one other potential exploit Ilia covered, which I didn't write down because I was running low on battery power. If I remember it, I'll update this entry.