<?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>Sat, 18 May 2013 19:39:44 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Joseph Scott's Blog: Why PHP Strings Equal Zero]]></title>
      <guid>http://www.phpdeveloper.org/news/17679</guid>
      <link>http://www.phpdeveloper.org/news/17679</link>
      <description><![CDATA[<p>
<i>Joseph Scott</i> has a new post to his blog looking at "<a href="http://josephscott.org/archives/2012/03/why-php-strings-equal-zero/">why PHP strings equal zero</a>" - that when you use the "==" operator on a string to compare to zero, it's true.
</p>
<blockquote>
The issue of PHP strings equaling zero has come up a few times recently. [...] Running that will display Equals zero!, which at first glance probably doesn't make much sense. So what is going on here?
</blockquote>
<p>
He gets into the specifics of what's happening - a bit of type jugging, less strict comparison since it's the "==" versus "===" and how the <a href="http://php.net/manual/en/language.types.string.php">PHP manual</a> talks about strings being converted to numbers. 
</p>
<blockquote>
While I still think it is odd that the string gets cast as an integer instead of the other way around, I don't think this is a big deal. I can't recall a single time where I've ever run into this issue in a PHP app. I've only seen it come up in contrived examples like the ones above.
</blockquote>]]></description>
      <pubDate>Thu, 15 Mar 2012 09:47:49 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Brandon Savage's Blog: An XSS Vulerability In The Making]]></title>
      <guid>http://www.phpdeveloper.org/news/17640</guid>
      <link>http://www.phpdeveloper.org/news/17640</link>
      <description><![CDATA[<p>
<i>Brandon Savage</i> has a new post to his blog about what he calls a <a href="http://www.brandonsavage.net/an-xss-vulerability-in-the-making/">XSS vulnerability in the making</a>, something to watch out for when you're doing validation in PHP involving the possibility of numbers as strings.
</p>
<blockquote>
Back in September, <a href="https://crash-stats.mozilla.org/">Socorro</a> received a <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=689675">security bug</a> relating to the method we were using for processing inputs for the duration of certain reports. The vulnerability included a proof of concept, with an alert box popping up on production when the link was followed. [...] I was quite surprised at the root cause of the vulnerability. We had opted to compare the incoming data against a known set of valid values - a common practice when whitelisting certain inputs. [...] As expected, when this [example] code is tested, a string of '3' and an integer of 3 work equally well, and a string of '5' and an integer of 5 fail equally. 
</blockquote>
<p>
This automatic casting that PHP does internally caused another issue as well - if the string passed in even started with a valid number from their whitelist set, it still passed.
</p>
<blockquote>
At first we thought this surely had to be a bug in PHP. However, Laura Thomson told me "If comparing two values, type juggling is performed first, which means that the string is converted to a number. This is done by <a href="http://us2.php.net/manual/en/language.types.string.php#language.types.string.conversion">taking the first number found in the string</a>. So this may be confusing/a quirk/a gotcha, but it isn't a bug." And she's right: this isn't a bug per se, but it's certainly an interesting "gotcha."
</blockquote>]]></description>
      <pubDate>Wed, 07 Mar 2012 12:02:46 -0600</pubDate>
    </item>
  </channel>
</rss>
