I was wondering today why use mbstring rather than iconv in Dokeos, and honestly I didn't remember exactly why I had chosen mbstring in the past, but finding information about the *differences* between the two. [...] Searching a bit more, I found a PPT presentation from Carlos Hoyos on Google.

Essentially, it boils down to how the library is integrated - mbstring is bundled and iconv is pulled from an external source. So, if you're looking for maximum portability, he recommends mbstring.

I was finding a way to refer that element as a SimpleXMLElement and found a nifty note in PHP Manual. It says if you have unsupported (unsupported in PHP Lexicon for a variable name) characters inside the name of a node, you can access it using a special pattern {'name'}.

In his example, he shows how a popular phrase ("i can have cheese burger") can be used as the variable name despite having spaces in it.

In the post [on Good and Bad PHP Code], he provides a few useful PHP interview questions, including some questions from Yahoo. He explains that good PHP code should be Structured, Consistent, Portable and Secure

In the comments, many additional improvements have been suggested, but there's one that has yet to be mentioned. When using htmlspecialchars() without specifying the character encoding, XSS attacks that use UTF-7 are possible.

Included in the post is an example to illustrate the point as well as a solution, a simple one involving the header() function, to help correct the problem and prevent bad things from happening.

Be sure to check out the comments for more great tips.]]> Wed, 20 Jun 2007 09:35:00 -0500 http://www.phpdeveloper.org/news/8063 http://www.phpdeveloper.org/news/8063 In a new post to the PHP Security Blog, Stefan Esser points out a recent commit to the PHP core as a fix to the session handling in PHP:

I just came back home and saw a very recent commit to PHP's session management. It is another attempt to fix the session cookie attribute injection that the PHP developers already tried to fix in PHP 5.2.3 without giving any credits. [...] their new fix that consists of blacklisting a bunch of legal characters from the session id, will most probably result in hundreds or thousands of broken sites.

Stefan points out that the fix blocks several valid characters that sites could potentially use in their session IDs, and that with this new code in place, it could drastically effect those site's functionality.

As of the time of this post, however, it seems that the issue has been recognized and corrected so as not to cause the above mentioned issue in future updates.

As a result of all the noise about UTF-8, got an email from Marek Gayer with some very smart tips on handling UTF-8. What follows is a discussion illustrating what happens when you get obsessed with performance and optimizations (be warned - may be boring, depending on your perspective).

He talks mainly about using the native PHP functionality to avoid the mbstring issues that could arise by restricting locale behavior and using a fast case conversion function to handle strings correctly. The other tip involves delivery methods to those not able to recieve UTF-8 formatted content - checking their character set and responding accordingly.

From this post: The recent cross-site scripting (XSS) vulnerability discovered in Google perfectly illustrates why character encoding matters. This example demonstrates how to use PHP's htmlentities() with the optional third argument that indicates the character encoding.

By way of demonstration, he provides a little PHP script that makes a request in a different character encoding than Google can handle. Coupled with the small response from Google, a UTF-7 character sent to certain browsers could be interpreted and executed.

In this second post, he answers a question from the comments - "how will this effect my site?"

Rather than offer another vague answer, I decided to provide a very simple proof of concept that demonstrates how character encoding inconsistencies can bite you. Google's vulnerability has of course been fixed, but with a simple PHP script, we can reproduce the situation.

The script, though escaped, still causes a Javascript popup box to show when the page is loaded - all due to a lack of improper character encoding handling...]]> Thu, 22 Dec 2005 06:19:39 -0600