D-talk (Entries tagged as apache)

Multiple PHP versions on one webserver

nospam@example.com (Mark van der Velden) — Tue, 03 Nov 2009 08:39:00 +0100

Introduction

This is a blog about running two PHP versions on one webserver and using multiple php.ini files, this combination can be a tricky one to tackle. But luckily one we can tackle quite easily as long as one of the PHP versions is >= 5.2.7. For this example I'll be using Apache, but the webserver flavor doesn't really matter. The most important part is the "PHP_INI_SCAN_DIR" environment variable.

The why

There could be a number of reasons to want what I'm about to talk about. In my case I have a project where I have a legacy code-base, running on a specific PHP version, and a new code-base which will be run on 5.3. Because the new code-base will be a ongoing progress of replacing the old, it first has to run side by side with the legacy code-base. So I wanted my development image to run two PHP versions.

The old code-base used php.ini settings such as a include-path, error reporting, etc. Which will be different from the new code-bas, and those can no-longer be set with the 'php_value' feature of Apaches since the PHP version we'll be using for that runs as (f)CGI rather then as module.

Continue reading "Multiple PHP versions on one webserver"

Apache's fail with 'encoded slashes'

nospam@example.com (Mark van der Velden) — Thu, 25 Jun 2009 14:58:45 +0200

Honestly it took me a while to debug a vague bug I had, at first I ignored it and used different path values, figuring it was a bad rewrite rule. I'm using a project and I'm developing on both Apache and IIS, with the one inconsistency that I always got a 404 when the path contained a encoded /, namely "%2F". So basically, a URL like this: http://domain.com/show/article/104671-Situation%20details%20n%2Fa (Title being: "Situation details n/a") is giving a 404. The error log was helpful, because it said:

[..] [info] [client 127.0.0.1] found %2f (encoded '/') in URI (decoded='//'), returning 404

Luckily, fixing this ~~bug~~ feature is easy. Add the following to your httpd.conf (vhost or server directive) and voila:

AllowEncodedSlashes On

Arguably you could be saying that %2F's simply shouldn't be in the path, but rather in the POST body or as GET parameter. However in a world where everything has to be SEO and url's have to be pretty, isn't this silly default behavior ? Especially since the RFC's also clearly state that an encoded forward slash (%2F) should not be treated as a regular '/'. To quote RFC 2616

Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.

and RFC 2396

2.2. Reserved Characters

   Many URI include components consisting of or delimited by, certain
   special characters.  These characters are called "reserved", since
   their usage within the URI component is limited to their reserved
   purpose.  If the data for a URI component would conflict with the
   reserved purpose, then the conflicting data must be escaped before
   forming the URI.

      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                    "$" | ","

Be careful with double extensions

nospam@example.com (Mark van der Velden) — Fri, 24 Oct 2008 13:43:00 +0200

Since I'm on a 'finish blog drafts' spree, I might as well publish this one also. I actually had it in draft for about 5 months now anyway.

In most upload tools files are checked on extensions only, while it might seem pretty solid it's actually not as safe as you might think. Especially in combination with Apache and mod_mime.

When you do:
rename image.jpg image.txt and you request it: domain.com/image.txt you get garbled text.

However when you try something like this:
rename file.php file.php.bogus and you request it: domain.com/file.php.bogus PHP code within the file is handled by the handler set for that extension.

Before you get all excited, the scenario when this happens is not likely to happen, because it only works for unknown file extensions. So basically, this can only happen when you work with black-listing rather then white-listing. And when checking files, you shouldn't be black-listing in the first place. Let's go into detail about the why.

Continue reading "Be careful with double extensions"