Planet PHPPeople blogging about PHPhttp://www.planet-php.net/ Planet PHP Aggregator 2006-01-23T16:40:00ZeZ components in Gentoo LinuxSebastian Bergmannhttp://www.sebastian-bergmann.de/blog/archives/565-guid.html2006-01-23T16:40:00Z2006-01-23T16:40:00ZeZ components, which provide an enterprise ready general purpose PHP platform, are now available through Gentoo Linux's portage system:
wopr-mobile ~ # emerge -vp ezc-eZcomponents

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] app-admin/php-toolkit-1.0-r2  0 kB
[ebuild  N    ] dev-lang/php-5.1.2  0 kB [3]
[ebuild  N    ] dev-php/PEAR-PEAR-1.4.6  0 kB [2]
[ebuild  N    ] dev-php5/ezc-Base-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-Database-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-PhpGenerator-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-Configuration-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-ImageAnalysis-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-Archive-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-Translation-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-Cache-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-ConsoleTools-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-PersistentObject-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-ImageConversion-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-Mail-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-UserInput-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-Debug-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-EventLog-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-Execution-1.0_rc1  0 kB [2]
[ebuild  N    ] dev-php5/ezc-eZcomponents-1.0_rc1  0 kB [2]

Total size of downloads: 0 kB
Portage overlays:
 [1] /usr/local/overlay/personal
 [2] /usr/local/overlay/cvs
 [3] /usr/local/overlay/php/testing
 [4] /usr/local/overlay/php/experimental
 [5] /usr/local/overlay/gentopia
 [6] /usr/local/overlay/xgl
]]>
PHP InsecurityChris Shifletthttp://shiflett.org/archive/1852006-01-23T16:15:00Z2006-01-23T16:15:00ZAndrew van der Stock has written a strong criticism of PHP's insecurity. Andrew is a seasoned security expert and a major contributor to OWASP, and he states:

After writing PHP forum software for three years now, I've come to the conclusion that it is basically impossible for normal programmers to write secure PHP code. It takes far too much effort.

He continues, citing specific areas where he thinks PHP is weak and asserting that "PHP must now mature and take on a proper security architecture."

Many of the insecure features he cites (register_globals, magic_quotes_gpc, and safe_mode) are slated to be removed in PHP 6, but his core complaint seems to revolve around the fact that PHP makes too much power too easily accessible, often granting developers more power and flexibility than they realize (e.g., wrappers).

Aside from minor language features like taint mode, I don't see what other platforms offer to help prevent inexperienced developers from writing insecure code. Anyone care to enlighten me? :-)

Posted Mon, 23 Jan 2006 16:15:56 GMT in Chris Shiflett: The PHP Blog
[   Discuss   |   Tag   |   Digg   |   Furl   |   Cosmos   ]

]]>
Beta release of mobile webmail client (MIMP)Horde Newshttp://janschneider.de/cweb/home/index,channel,25,story,255.html2006-01-23T10:01:00Z2006-01-23T10:01:00ZMeet me at php|tekThinkPHP /dev/blog - PHPhttp://blog.thinkphp.de/archives/81-guid.html2006-01-22T22:34:00Z2006-01-22T22:34:00Zphp|tek, the next conference from the php|arch guys around Marco Tabini who already organized the php|cruise and php|tropics conferences, will be from April 26th to 28th at Orlando, Florida. As you can read on the recently published schedule I'll hold two talks. The first talk will be about PHP on the command line, showing PHP's strength beyond the web which can be helpful to build, deploy and scale your web-application and even for building apps completely independent from anything on the web. My second talk will be about PHP's reflection API. In that session I'll give an introduction into the API and show how to use it to build modular, dynamic applications.

If you're in reachable distance you should take the chance to listen and meet PHP developers from all over the world. (Hint: Till January 31st you can get early-bird rates!)

johannes

]]>
Quick LookupJohn Coxhttp://wyome.com/index.php?module=articles&func=display&ptid=10&catid=29-31&aid=5072006-01-22T19:23:00Z2006-01-22T19:23:00ZQuick lookup is a very nice little reference tool for lookups of web development documentation. It installs as a simple bookmark which can be changed to your sidebar for look ups of php / css / javascript / mysql documentation. It has a limited scope of features (which isn't a bad thing in my mind):

* Multiple tabs
* PHP / MySQL / CSS / JS reference (MySQL is 55% complete)
* Examples
* Search as you type
* Fast results
* Remembers your last tab on your revisit
* Access keys, [alt + (p, m, j, c)]

I did a cursory install, and it appears to be pretty fast. I think it might be better as part of the Web Developer Extension for Firefox, but as is, I can see the uses.

]]>
mysql_real_escape_string() versus Prepared StatementsIlia Alshanetskyhttp://ilia.ws/archives/103-guid.html2006-01-22T18:03:00Z2006-01-22T18:03:00ZChris 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'

Truncated by Planet PHP, read more at the original (another 2694 bytes)

]]>
The addslashes() Versus mysql_real_escape_string() DebateChris Shifletthttp://shiflett.org/archive/1842006-01-22T04:15:00Z2006-01-22T04:15:00ZLast month, I discussed Google's XSS Vulnerability and provided an example that demonstrates it. I was hoping to highlight why character encoding consistency is important, but apparently the addslashes() versus mysql_real_escape_string() debate continues. Demonstrating Google's XSS vulnerability was pretty easy. Demonstrating an SQL injection attack that is immune to addslashes() is a bit more involved, but still pretty straightforward.

In GBK, 0xbf27 is not a valid multi-byte character, but 0xbf5c is. Interpreted as single-byte characters, 0xbf27 is 0xbf (¿) followed by 0x27 ('), and 0xbf5c is 0xbf (¿) followed by 0x5c (\).

How does this help? If I want to attempt an SQL injection attack against a MySQL database, having single quotes escaped with a backslash is a bummer. If you're using addslashes(), however, I'm in luck. All I need to do is inject something like 0xbf27, and addslashes() modifies this to become 0xbf5c27, a valid multi-byte character followed by a single quote. In other words, I can successfully inject a single quote despite your escaping. That's because 0xbf5c is considered to be a single character, not two. Oops, there goes the backslash.

I'm going to use MySQL 5.0 and PHP's mysqli extension for this demonstration. If you want to try this yourself, make sure you're using GBK. I just changed /etc/my.cnf, but that's because I'm testing locally:

[client]
default-character-set=GBK

Create a table called users:

CREATE TABLE users
(
    username VARCHAR(32) CHARACTER SET GBK,
    password VARCHAR(32) CHARACTER SET GBK,
    PRIMARY KEY (username)
);

The following script mimics a situation where only addslashes() is used to escape the data being used in a query:

<?php 

$mysql 
= array();

$db mysqli_init();
$db->real_connect('localhost''myuser''mypass''mydb');

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

$mysql['username'] = addslashes($_POST['username']);
$mysql['password'] = addslashes($_POST

Truncated by Planet PHP, read more at the original (another 4165 bytes)

]]>
PHP ConferencesJason E. Sweathttp://blog.casey-sweat.us/?p=692006-01-22T04:04:00Z2006-01-22T04:04:00ZBack from NorwayTobias Schlitthttp://www.schlitt.info/applications/blog/index.php?/archives/407-guid.html2006-01-22T00:30:00Z2006-01-22T00:30:00ZNorway is a somewhat strange country. When I got there - 2 weeks ago to work with Amos, Derick, Fred and Ray on the eZ components - it had the expected amount of snow. A few days later, there was nothing anymore. We had positive celsius values and the weather was really crappy... until Monday. Since then it has been snowing all the time and yesterday we left when it looked like this:

pict1285.jpg

Nice to watch, but not real fun to walk onto. :) Anyway, it's been another great stay in Skien, where the eZ headquarter is and I'm pretty much looking forward to our summer conference, where we plan to have the complete eZ team there and lots of people from the PHP world. Thanks for the great time, folks!

]]>
Solar 0.10.0 ReleasedPaul M. Joneshttp://paul-m-jones.com/blog/?p=1922006-01-21T21:44:00Z2006-01-21T21:44:00Z