<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Tue, 08 Jul 2008 22:35:58 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Dokeos Blog: mbstring vs iconv]]></title>
      <guid>http://www.phpdeveloper.org/news/10034</guid>
      <link>http://www.phpdeveloper.org/news/10034</link>
      <description><![CDATA[<p>
In <a href="http://dokeoslead.wordpress.com/2008/04/22/mbstring-vs-iconv/">this post</a> on the Dokeos blog, there's a comparison of the <a href="http://www.php.net/mbstring">mbstring</a> function and the <a href="http://php.net/iconv">iconv</a> library as it pertains to their use on multi-byte strings.
</p>
<blockquote>
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 <a href="http://www.nyphp.org/content/presentations/smallworld/April2006-nyphp-Presentation.ppt">PPT presentation</a> from Carlos Hoyos on Google.
</blockquote>
<p>
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.
</p>]]></description>
      <pubDate>Thu, 24 Apr 2008 11:18:08 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Chris Shiflett's Blog: Google XSS and Evil Character Encoding]]></title>
      <guid>http://www.phpdeveloper.org/news/4540</guid>
      <link>http://www.phpdeveloper.org/news/4540</link>
      <description><![CDATA[On his blog today, <i>Chris Shiflett</i> has two posts about a problem with Google and a Cross-site Scripting attack that it's vulnerable to.
<p>
From <a href="http://shiflett.org/archive/177">this post</a>:
<quote>
<i>
The recent cross-site scripting (XSS) vulnerability discovered in Google perfectly illustrates why character encoding matters. <a href="http://phpsecurity.org/code/ch01-4">This example</a> demonstrates how to use PHP's htmlentities() with the optional third argument that indicates the character encoding.
</i>
</quote>
<p>
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.
<p>
In <a href="http://shiflett.org/archive/178">this second post</a>, he answers a question from the comments - "how will this effect my site?"
<p>
<quote>
<i>
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.
</i>
</quote>
<p>
<a href="http://shiflett.org/archive/178">The script</a>, 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...]]></description>
      <pubDate>Thu, 22 Dec 2005 06:19:39 -0600</pubDate>
    </item>
  </channel>
</rss>
