PHP - 9

Every web developer knows how to make a GET redirect, in fact they've probably done it numerous times. However very few people know the same can be done for POST requests, in some instances completely transparently to the user. This by itself make not seem like an issue, but when you combine it with XSS it can be a very powerful to used to scam users.

Consider the following scenario. A user goes to a trusted site where XSS had modified the action field of the login POST form, pointing it to http://p0wn3d.com/post.php. When user submits a request it goes to a 3rd party site, which captures the login credentials and then redirects the POST data to the original site. In the end to the user has no clue something sinister had happened because they never see p0wn3d.com. In fact the everything appears to have worked as intended.

So how does this work. Ability to redirect POST comes as a courtesy of the little known 307 redirect code. Which in PHP can be forced in the following manner:



Now, according to the RFC

"If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued."

Alas, unlike the Opera and FireFox developers, the IE developers have never read the spec, and even the latest, most secure IE7 will redirect the POST request from domain A to domain B without any warnings or confirmation dialogs! Safari also acts in an interesting manner, while it does not raise a confirmation dialog and performs the redirect, it throws away the POST data, effectively changing 307 redirect into the more common 302.

The 2nd release candidate for PHP 5.2.1 is now available for download. The tarballs can be found here:

http://downloads.php.net/ilia/php-5.2.1RC2.tar.bz2 (cc6024531e3d4058e32cf740e2fe535f)
http://downloads.php.net/ilia/php-5.2.1RC2.tar.gz (3f89c31687762a39f1360b380dd315b4)

Since the last release over 30 different bug fixes were made and the two pending patches relating to is_numeric_string() optimization and internal heap protection for the Zend Engine allocator were added. Another important change was the fact that the memory limit is now always enabled and to accommodate this change the default limit value was raised to 128 megabytes to avoid script breakage. We do not anticipate any regressions to be introduced by this RC, but I would still like to ask everyone to take a few minutes and test it against their code base. If you come across any issues report them via http://bugs.php.net/ or reply to this blog post.

The first release candidate of PHP 5.2.1 scheduled for late January is now available for download. The tarballs can be found here:

php-5.2.1RC1.tar.bz2 (md5sum: cc6024531e3d4058e32cf740e2fe535f)
php-5.2.1RC1.tar.gz (md5sum: bafcdff32bcaa564f65293c1c42d117e)

For win32 users binaries are available courtesy of Edin

php-5.2.1RC1-Win32.zip (md5sum: 00d6833308931fa58581574b8d364e12)
php-debug-pack-5.2.1RC1-Win32.zip (md5sum: ac86975945193455658d85921d835e60)

This release is primarily aimed at improving the stability of the language and finalization of features introduced in 5.2.0. There are over 70 different bug fixes, a great deal of performance improvements for Windows users, corrections to the memory manager and the improvement in the filter functionality. I'd like to ask everyone to try this release out and let us know if you come across any issues and/or regressions.

One of the common problems faced by web hosting companies offering PHP is the abuse of the mail() function to send spam. This problem has became further exasperated lately due to use of automated tools that seek sites vulnerable to PHP code execution and use the security hole to inject mailer code that then proceeds to send tons of spam.

This of course causes a series problem for a web host such as increased server load, possibility of getting blacklisted and thus having all mail generated by the server rejected and even problems with an up-stream provider.

One of the problems with solving the mail() abuse is figuring out who is doing it or perhaps what script was exploited to do it, since the mail() function does not offer any logging mechanism. The uid identifier is generally useless because when PHP is ran as an Apache modules all script share the web server's uid, which yet another reason to use FastCGI.

To address this problem one my client's had asked me to write a mail() logging and tracking facility that can be used to quickly identify the offending scripts and was kind enough to permit me to share the code with with the community.

The mailing logging patch, which you can download here, offers two features which can be controlled via INI settings for the entire PHP setup or on a per-virtual-host level.

The first option, mail.add_x_header (boolean) allows you to enable the addition of the X-PHP-Originating-Script header to each mail sent by mail(), which will include the uid of the script and its name. The combination of the two should be sufficient to identify the user to whom the script belongs and via a simple find command locate the actual script. This option is intended primarily for instances where you have a bounced e-mail or a forwarded mail with a spam complaint, allowing you to quickly identify the offender.

The second option, mail.log (takes a filename) allows you to enable logging of every single mail() call, each log line will include the fullpath of the file and the line where the mail() was called from in addition to the "To" address and any headers (to keep track of CC, BCC) that were part of the function call. To ensure that each log line is 1 line long, \r and \n are replaced with spaces.

There was a very interesting article posted on the Securiteam blog which talks about anonimizing code injection attacks. The approach is quite simple and yet rather ingenious, simply submit to Google the vulnerable application URL with the attack payload passed via the GET parameters. And within a short period of time Googlebot will dutifuly trying to index the URL, effectively executing the attack. Stefan had also explored this issue on his blog with some examples showing how to ensure more rapid indexing, so you wouldn't have to wait weeks for exploit to be triggered.

However, everybody seemed to have focus on Google, which maybe a bit unfair to them since other search engines suffer the same kind of problems. For example if we take MSN (Microsoft's Search) and run the "inurl:cmd.gif" query that SecuriTeam folks used to test Google, we find a fair number of results. Which tells us that hackers believe in equal opportunity and use MSN as much as Google to propagate their attacks.

But there are other ways too. For example an attack could post an anonymous message on a blog or a forum with an image embedded into where the image url is not an image but rather a URL vulnerable site with embed payload. Which means that when other people read their message their browsers in most cases will make requests to the given URL thus triggering the attack. This is hardly new though, this scam has been used for ages to inflate hit counter stats, etc... Another vector of attack could be to use application that retrieve content from a URL automatically, such as the w3c validator, that will instantly make a request to any given URL and more over return you the resulting HTML at the time obscuring the actual attacker's IP address.

It be interesting to know what other sites allow this kind of behavior where a user supplied URL is instantly retrieved hiding the original user's IP.

Damien is continuing his very handy phpinfo() research work, this time focusing on the popularity of the different PHP extensions people utilize with PHP and some interesting configuration directives such as disable_functions. You can find the graphs and summaries here and here.

A very interesting read to anyone writing or considering writing distributable applications that need to work in different PHP environments.

After an extremely long (IMO) release cycle the final version of PHP 5.2.0 was finally released yesterday morning. There are many new features, speed improvements and a fair number of security changes. You can read the official release announcement for a quick summary of the major changes and the specifics can be found in a very long and somewhat boring to read changelog

The bottom line is that all users of PHP 5.x should definitely upgrade and for 4.x users need to seriously start thinking about migrating as well, since we've finally got a 5 release that not only is feature complete but is also faster or at the minimum performs at the same speed as PHP 4.4.

Big thanks to all the contributors who made patches, reported bugs and ran tests to hopefully make a solid release.

The slides for the Caching Systems talk are now available online, they can be downloaded here.