iBlog - Ilia Alshanetsky

Entries from January 2006

Quicksearch

Calendar

Syndicate This Blog

Comments

Sunday, January 29. 2006

php|tek 2006 Posted by Ilia Alshanetsky in PHP at 16:35

Comments (0)
Trackbacks (0)

My proposal for the php|tek 2006 conference have been approved, which means that I'll be flying to sunny Florida this spring. Given the gloomy weather here in Toronto, it certainly sounds like a lot of fun. On the conference's agenda I have just two items this time; I will be giving an introductory talk on PDO that should be of interest to anyone writing new PHP applications that utilize databases. The other item is a seminar on PHP Security, which will cover web security topics from the ground up, with the focus on web applications designed in PHP. Aside from my own talks, Marco has collected an impressive array of speakers with notables such as Rasmus, Marcus, Derick, John, Sara (who I've never met in real life

) and many others. So if you need to get away from the day to day drudgery and learn something about PHP in the process, this a conference you don't want to miss!

Sunday, January 22. 2006

mysql_real_escape_string() versus ... Posted by Ilia Alshanetsky in PHP at 13:03

Comments (18)
Trackbacks (4)

mysql_real_escape_string() versus Prepared Statements

Chris has written a compelling piece about how the use of addslashes() for string escaping in MySQL queries can lead to SQL injection through the abuse of multibyte character sets. In his example he relies on addslashes() to convert an invalid multibyte sequence into a valid one, which also has an embedded ' that is not escaped. And in an ironic twist, the function intended to protect against SQL injection is used to actually trigger it.

The problem demonstrated, actually goes a bit further, which even makes the prescribed escaping mechanism, mysql_real_escape_string() prone to the same kind of issues affecting addslashes(). The main advantage of the mysql_real_escape_string() over addslashes() lies in the fact that it takes character set into account and thus is able to determine how to properly escape the data. For example, if GBK character set is being used, it will not convert an invalid multibyte sequence 0xbf27 (¿’) into 0xbf5c27 (¿\’ or in GBK a single valid multibyte character followed by a single quote). To determine the proper escaping methodology mysql_real_escape_string() needs to know the character set used, which is normally retrieved from the database connection cursor. Herein lies the “trick”. In MySQL there are two ways to change the character set, you can do it by changing in MySQL configuration file (my.cnf) by doing:

CODE:

[client]
default-character-set=GBK

Or you can change on a per-connection basis, which is a common practice done by people without admin level access to the server via the following query:

CODE:

SET CHARACTER SET 'GBK'

The problem with the latter, is that while it most certainly modified the charset it didn’t let the escaping facilities know about it. Which means that mysql_real_escape_string() still works on the basis of the default charset, which if set to latin1 (common default) will make the function work in a manner identical to addslashes() for our purposes. Another word, 0xbf27 will be converted to 0xbf5c27 facilitating the SQL injection. Here is a brief proof of concept.

PHP:



<?php



$c = mysql_connect("localhost", "user", "pass");

mysql_select_db("database", $c);



// change our character set

mysql_query("SET CHARACTER SET 'gbk'", $c);



// create demo table

mysql_query("CREATE TABLE users (

    username VARCHAR(32) PRIMARY KEY,

    password VARCHAR(32)

) CHARACTER SET 'GBK'", $c);

mysql_query("INSERT INTO users VALUES('foo','bar'), ('baz','test')", $c);



// now the exploit code

$_POST['username'] = chr(0xbf) . chr(0x27) . ' OR username = username /*'; 

$_POST['password'] = 'anything'; 



// Proper escaping, we should be safe, right?

$user = mysql_real_escape_string($_POST['username'], $c);

$passwd = mysql_real_escape_string($_POST['password'], $c);



$sql = "SELECT * FROM  users WHERE  username = '{$user}' AND password = '{$passwd}'";

$res = mysql_query($sql, $c);

echo mysql_num_rows($res); // will print 2, indicating that we were able to fetch all records



?>

So what can you do? The solution is to use prepared statements, which are supported by nearly all PHP database extensions with the notable exceptions of MySQL (ext/mysql) and SQLite2 (ext/sqlite). So, to be on the safe side, I'd recommend using the PDO interface to talks with those databases or in the case of MySQL using the newer MySQLi (ext/mysqli) extension. Those interfaces provide prepared statement support, which allows for separation between query structure and the query parameters. It should be noted that while PDO does emulated prepared statements for older versions of MySQL that do not support them natively, emulation is still prone to the same kind of issues demonstrated here and in Chris’ article. Therefore for security reasons you should definitely consider upgrading to a more modern version of MySQL and SQLite (SQLite 3).

Thursday, January 12. 2006

5.1.2 Released! Posted by Ilia Alshanetsky in PHP at 10:44

Comments (2)
Trackbacks (2)

5.1.2 Released!

This morning I've released PHP 5.1.2 , which is a culmination of about 3 months work by PHP developer community. Big thanks to all the developers who have spent the time to make this release possible. This release combines some new features, a fair number of bug fixes and even addresses a few security bugs. If you are using PHP 5, this release is definitely worth upgrading to. The major changes can be found in the release announcement, while if you want to read the entire changelog, you can find it here.

Surprisingly enough unlike most PHP release this one was actually right one time and followed the release plan I've made to the letter, hopefully this is something we can keep up.

A little bit of trivia, PHP 5.1.2 is my 12th PHP release, which coincidentally was released on January the 12th

Wednesday, January 11. 2006

Yahoo Search Filtering Posted by Ilia Alshanetsky in Stuff at 16:55

Comments (3)
Trackbacks (0)

Yahoo Search Filtering

It appears that when it comes to search for filenames, Yahoo's search engine uses some heavy handed techniques to filter out results for queries that may expose sensetive information. Interestingly enough it would appear that Yahoo is unique in this approach as other search engines namely Google and Lycos do not appear to believe in such form of filtering.

To illustrate this filering consider the search for "config.inc" inside the URL, this can be done on both Google and Yahoo via the inurl:"config.inc" query. While you may expect approximately the same number of results, this is not the case, Google finds approximately 884 pages, while Yahoo finds none!

While the config.inc file can potentially contain sensetive data, many PHP applications use it to store their settings, what's wrong with "ey.txt" file? Again Google finds us some results, 32 to be precise, while Yahoo is consistent with 0.

Why would they block "ey.txt"? Well, ey.txt happens to a suffix of rather interesting file "cdkey.txt"

, which appears in Johnny's Files containing juicy info list. I suspect to prevent people from bypassing the cdkey.txt search filter, all "suffixes" of cdkey.txt results are being blocked. This theory is supported by the fact that the search for URLs with "key.txt" in them return 0 on Yahoo, familiar sight, while on Google we see 993 results.

Thursday, January 5. 2006

PHP 5.1.2RC2 Released! Posted by Ilia Alshanetsky in PHP at 20:02

Comments (3)
Trackbacks (2)

PHP 5.1.2RC2 Released!

The second and final RC of 5.1.2 was packaged today and is now available for download. This has been a purely bug fix RC that addresses a number of crash bugs and does a bit of further tweaking on the date
functionality. Please test it as much as you can, since pending any major problems this becomes the final release on January 12th.

The sources can be downloaded from:
http://downloads.php.net/ilia/php-5.1.2RC2.tar.bz2
0a24a22552ae966afa3e0f3da2f1c47d

http://downloads.php.net/ilia/php-5.1.2RC2.tar.gz
7aee42982a8a16a0d600e1ef46dadec6

Win32 binaries should be available shortly from
http://downloads.php.net/ilia/ as well.

If you know of any regressions introduced by this release, please let me know.

Tuesday, January 3. 2006

GDChart & Fileinfo Releases Posted by Ilia Alshanetsky in PHP at 16:08

Comments (10)
Trackbacks (0)

GDChart & Fileinfo Releases

Just finished packaging Fileinfo 1.0.3 that finally builds on both PHP 5.1 and 5.0 properly. You can download the new version by running "pecl install fileinfo" or download the tgz file from here.

I've also made the release of GDChart 0.2 that is nearly a complete rewrite of the extension, originally written by Rasmus that allows it to work with PHP 5.1. This extension wraps around the bundled gdchart library and allows you with just a few lines of code draw 20 different graphs types. Like all pecl extensions it can be installed by running "pecl install gdchart" or you can download the tar ball from here. Since at the moment there is no documentation for the extension, here are a few examples of its usage: Continue reading "GDChart & Fileinfo Releases"

Monday, January 2. 2006

FUDforum 2.7.4RC1 Released Posted by Ilia Alshanetsky in FUDforum at 13:05

Comments (0)
Trackbacks (0)

FUDforum 2.7.4RC1 Released

A little over 2 months have passed since the last stable release, and so we are once again on the release road starting with 2.7.4RC1. This release combines both bug fixes as well as a fair number new features, so there is something for everyone

. Given the long delay since the last release by FUDforum standards, the list of changes is quite impressive.

The upgrade and installation scripts are available at the urls listed below:
Install Script
Upgrade Script

To see full list of changes is available below:
Continue reading "FUDforum 2.7.4RC1 Released"

« previous page (Page 1 of 1, totaling 7 entries) next page »
Frontpage

Guide to PHP Security