<?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, 18 Jun 2013 23:37:32 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[P&aacute;draic Brady's Blog: XSS in PHP (Part 1): How Not to Use Htmlspecialchars]]></title>
      <guid>http://www.phpdeveloper.org/news/17667</guid>
      <link>http://www.phpdeveloper.org/news/17667</link>
      <description><![CDATA[<p>
<i>P&aacute;draic Brady</i> has <a herf="http://blog.astrumfutura.com/2012/03/a-hitchhikers-guide-to-cross-site-scripting-xss-in-php-part-1-how-not-to-use-htmlspecialchars-for-output-escaping/">written up an exhaustive guide</a> to using <a href="http://php.net/htmlspecialchars">htmlspecialchars</a> correctly and securely in your applications (though it's technically how "not to use it"). This is part one of a series looking at preventing cross-site scripting in PHP applications.
</p>
<blockquote>
<p>
While it's no harm poking fun at ourselves, in PHP we do have a serious problem. Cross-Site Scripting (XSS) remains one of the most significant classes of security problems afflicting PHP applications. Despite years of education, community awareness and the development of frameworks which can offer a huge boost in consistent practices - things are not getting any better.
</p>
<p>
So, I finally figured out what the core problem is: PHP programmers are completely clueless about XSS. It's that simple. Instead of going out and studying the topic, we blindly follow some preferred herd of people offering advice with heartfelt conviction despite the fact that they are probably just as ignorant as the rest of us. Does that sound like the behaviour of something which allegedly evolved into an intelligent species? The result is a mix of ignorance and stagnant knowledge that leaves PHP in an unenviable position beset by wrongheaded zealots.
</p>
</blockquote>
<p>
He introduces the <a href="http://php.net/htmlspecialchars">htmlspecialchars</a> function and how it has been generally assumed a good method for presenting XSS attacks.   He talks about issues with quotes, problems that IE6 seems to have that no one else does and the all-important third parameter of the function (character set detection) and the optional fourth (decoding HTML entities automatically). 
</p>
<p>
He's created <a href="https://github.com/padraic/xss">this github repository</a> with the examples from the post.
</p>]]></description>
      <pubDate>Tue, 13 Mar 2012 12:44:27 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Nikita Popov's Blog: htmlspecialchars() improvements in PHP 5.4]]></title>
      <guid>http://www.phpdeveloper.org/news/17462</guid>
      <link>http://www.phpdeveloper.org/news/17462</link>
      <description><![CDATA[<p>
In <a href="http://nikic.github.com/2012/01/28/htmlspecialchars-improvements-in-PHP-5-4">this new post</a> to his blog <i>Nikita Popov</i> looks at an update that might have gotten lost in the shuffle of new features coming in PHP 5.4 - some updates to <a href="http://php.net/htmlspecialchars">htmlspecialchars</a>.
</p>
<blockquote>
One set of changes that I think is particularly important was largely overlooked: For PHP 5.4 cataphract (Artefacto on StackOverflow) heroically rewrote large parts of htmlspecialchars thus fixing various quirks and adding some really nice new features. Here a quick summary of the most important changes: UTF-8 as the default charset, improved error handling (ENT_SUBSTITUTE) and Doctype handling (ENT_HTML401,...).
</blockquote>
<p>
He goes into each of these three main features in a bit more detail, providing code to illustrate the improved error handling and the new flags for Doctype handling (covering HTML 4.01, HTML 5, XML 1 and XHTML).
</p>]]></description>
      <pubDate>Mon, 30 Jan 2012 09:55:24 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Chris Shiflett's Blog: Character Encoding and XSS]]></title>
      <guid>http://www.phpdeveloper.org/news/8084</guid>
      <link>http://www.phpdeveloper.org/news/8084</link>
      <description><![CDATA[<p>
In <a href="http://shiflett.org/blog/2007/may/character-encoding-and-xss">this post</a> to his blog, <i>Chris Shiflett</i> talks about some issues surrounding character encoding and the cross-site scripting issues it can open up in your application.
</p>
<blockquote>
<p>
In the post [on Good and Bad PHP Code], he provides a few useful PHP interview questions, including <a href="http://blog.assembleron.com/2007/05/23/php-interview-questions-from-yahoo/">some questions from Yahoo</a>. He explains that good PHP code should be Structured, Consistent, Portable and Secure
</p>
<p>
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, <a href="http://shiflett.org/blog/2005/dec/google-xss-example">XSS attacks that use UTF-7</a> are possible.
</p>
</blockquote>
<p>
Included in <a href="http://shiflett.org/blog/2007/may/character-encoding-and-xss">the post</a> 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.
</p>
<p>
Be sure to check out <a href="
</p>http://shiflett.org/blog/2007/may/character-encoding-and-xss#comments">the comments</a> for more great tips.]]></description>
      <pubDate>Wed, 20 Jun 2007 09:35:00 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Secunia: Cisco Products PHP "htmlentities()" and "htmlspecialchars()" Buffer Overflows]]></title>
      <guid>http://www.phpdeveloper.org/news/7711</guid>
      <link>http://www.phpdeveloper.org/news/7711</link>
      <description><![CDATA[<p>
Cicso product users should check out <a href="http://secunia.com/advisories/25047/">this latest issue</a> Secunia has released today - a problem with the htmlentities and htmlspecialchars functions that can lead to buffer overflows.
</p>
<blockquote>
<p>
The vulnerabilities are caused due to boundary errors within the "htmlentities()" and "htmlspecialchars()" functions. If a PHP application uses these functions to process user-supplied input, this can be exploited to cause a heap-based buffer overflow by passing specially crafted data to the affected application.
</p>
<p>
Successful exploitation may allow execution of arbitrary code, but requires that the UTF-8 character set is selected.
</p>
</blockquote>
<p>
Products affected include the Network Analysis Modules (NAM) for Cisco 6500 switch, Cisco 7600 router/Branch Routers and the CiscoWorks Wireless LAN Solution Engine (WLSE) and CiscoWorks Wireless LAN Solution (among others, check out <a href="http://secunia.com/advisories/25047/">the advisory</a> for a more complete list). 
</p>
<p>
There are some patches that have been released to correct this issue (like the one for the Cisco Unified Application Environment) but others are still yet to come. They recommend limiting access to only trusted IPs and devices only to reduce the risk of the problem being exploited.
</p>]]></description>
      <pubDate>Thu, 26 Apr 2007 07:55:00 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[SitePoint PHP Blog: PHP Security - Dumb Users or Dumb APIs?]]></title>
      <guid>http://www.phpdeveloper.org/news/4727</guid>
      <link>http://www.phpdeveloper.org/news/4727</link>
      <description><![CDATA[On the SitePoint PHP Blog today, there's <a href="http://www.sitepoint.com/blogs/2006/01/24/php-security-dumb-users-or-dumb-apis/">a new post</a> from <i>Harry Fuecks</i> with his take on the whole "PHP security" issue that's being tossed around lately.
<p>
<quote>
<i>
There's another round of "Is PHP Secure?" debate happening right now. <a href="http://shiflett.org/archive/185">Chris</a> drew attention to it, pointing to a post by <a href="http://www.greebo.net/">Andrew van der Stock</a> (who's a contributor to <a href="http://www.owasp.org/">OWASP</a>): <a href="http://www.greebo.net/?p=320">PHP Insecurity: Failure of Leadership</a>.
<p>
So the usual denials have been made (see replies to Chris's entry) - "Damn newbies", "Holes in PHP-based app != PHP insecure", etc., all of which I agree with. But...
</i>
</quote>
<p>
He <a href="http://www.sitepoint.com/blogs/2006/01/24/php-security-dumb-users-or-dumb-apis/">also mentions</a> that this kind of talk could do more harm than good, making people that were on the edge lean back and take another look somewhere else. He also gives an example, a short bit of PHP and HTML that shines light on a typical XSS example - and asks if it's the developer's fault for not knowing, or the language's fault for not handling it right? Other topics he touches on as well are short tags and the use of filtering for all user input...]]></description>
      <pubDate>Wed, 25 Jan 2006 07:06:37 -0600</pubDate>
    </item>
  </channel>
</rss>
