Canonicalization and how it can be used on attacking PHP?

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
theNikki
Forum Newbie
Posts: 1
Joined: Mon Sep 26, 2005 11:12 am

Canonicalization and how it can be used on attacking PHP?

Post by theNikki »

Hello, could I have a piece of advice about this thing called "Canonicalization" and how it can used to attack PHP. I understand that characters can be presented in multiple ways. For example, '/' can be presented as '/', 0x2F, or even 0xc0xAF (="Overlong sequence") or even something else. Now, I've read from many resources that every input from user should be checked that way it doesn't include any "overlong sequences" (or urlencoded strings) and that way they can't "hide" true attack. Then I tried to demonstrate these "hidden" attacks, but they don't "work".

Here's my test environment:
PHP 4.2.3
Apache 2
Windows 95

Here's the simple demonstration I made:
1. I made a folder called "files"
2. I made a file called "read.php" and it only includes $_GET['file']
3. I made a php-file called file.php (on this "files" directory). This file only echoes "Hello"
4. I made another php-file called file.php on "higher" directory. This file only echoes "Attack"
5. I first included "files/file.php" by calling read.php?file=file.php. Worked ok (EG "Hello" was printed on browser)
6. Then I called the read.php with read.php?file=../file.php, which worked ok (EG "Attack" was printed on browser)..(on real code I wouldn't do this, it's just a demonstration on bad input validation)
7. Then I tried to "hide" the attack by calling read.php with overlong sequence of "/", as following : read.php?file=..%C0%AFfile.php, and it didn't "work" (EG "Attack" wasn't printed on browser)
8 I tried to "hide" attack by also urlencoding characters. %2F (="/") worked fine, but, for example %252F, didn't work, although many resources succests that it would..

So where is the point I've missed? If read.php includes files that are first utf8_decoded (include(utf8_decode($_GET['file'])) then these attacks would work, but not any other way..? Is it possible to "hide" attacks on php/apache/windows95 -environment? And how/why/why not? Does "hidden" attack need to have some other environment? Like ASP? Seems to me that "overlong sequnces" are threated as they are (EG characters, xC0xAF), and they have no special meanings (like they would mean /). I would be greatly thankful if anyone could help me..
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Post by Weirdan »

So where is the point I've missed? If read.php includes files that are first utf8_decoded (include(utf8_decode($_GET['file'])) then these attacks would work, but not any other way..? Is it possible to "hide" attacks on php/apache/windows95 -environment? And how/why/why not?
AFAIK, PHP does not consider incoming parameters to be utf8 unless you specifically process them as such (thus utf_decode($_GET['file'])) or set mbstring.http_input=UTF-8 (or auto) and mbstring.encoding_translation=On parameters in php.ini.
Post Reply