<?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>Mon, 20 May 2013 22:21:30 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Ruslan Yakushev's Blog: ASP.NET vulnerability affecting PHP sites on IIS]]></title>
      <guid>http://www.phpdeveloper.org/news/15173</guid>
      <link>http://www.phpdeveloper.org/news/15173</link>
      <description><![CDATA[<p>
As <i>Ruslan Yakushev</i> points out <a href="http://ruslany.net/2010/09/asp-net-vulnerability-affecting-php-sites-on-iis/">in this new blog entry</a>, the same security issue that's effecting ASP.NET pages running on IIS web servers can still open up PHP scripts running on the same server.
</p>
<blockquote>
Microsoft has recently released a Security Advisory about a security vulnerability in ASP.NET. This vulnerability exists in all versions of ASP.NET. The PHP applications running on IIS are also subject to this vulnerability if ASP.NET is enabled in IIS.
</blockquote>
<p>
The issue allows attackers to access the contents of various files on the server and could allow them to tamper with the data inside. <i>Ruslan</i> notes that, while Microsoft is coming up with a fix, one of the safest things you can do is either completely disable ASP.NET in the IIS server or <a href="http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx">use this workaround</a>.
</p>]]></description>
      <pubDate>Thu, 23 Sep 2010 08:50:46 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Pierre-Alain Joye's Blog: how to do not work around filter (don't be lazy :)]]></title>
      <guid>http://www.phpdeveloper.org/news/6960</guid>
      <link>http://www.phpdeveloper.org/news/6960</link>
      <description><![CDATA[<p>
On his blog, <i>Pierre-Alain Joye</i> <a href="http://blog.thepimp.net/index.php/post/2006/12/21/how-to-do-not-work-around-filter-dont-be-lazy-%3A">talks about</a> the ext/filter extension and how several developers just choose to "work around" it instead of using its features right out.
</p>
<blockquote>
On the other hand, the same persons worked around ext/filter with ugly hacks. Edin pointed me to one of these horrible codes in <a href="http://s9y.org/">Serendipity</a>, as I saw this code in other applications like <a href="http://flyspray.org/">flyspray</a>, I think it is time to raise your attention about what to do not do.
</blockquote>
<p>
The code he's referencing is <a href="http://blog.thepimp.net/index.php/post/2006/12/21/how-to-do-not-work-around-filter-dont-be-lazy-%3A">a snippet</a> that manually filters each of the superglobals to get rid of any problems that might have been put in. He points out two security problems with the code too: only use PHP functions as a fallback when filter isn't available and never use the superglobals directly outside of the filtering.
</p>
<p>
<i>Stefan Esser</i> has <a href="http://blog.php-security.org/archives/64-Why-extfilter.html">his own comments</a> on the topic too. He votes for the other way around (own functions over filter's methods) and expresses the opinion that the ext/filter extension is a bad idea similar to the impropper use of magic_quotes_gpc.
</p>
<p>
<i>Pierre</i> has also <a href="http://blog.thepimp.net/index.php/post/2006/12/21/how-to-do-not-work-around-filter-dont-be-lazy-%3A">responded to these comments</a> in an update to how own blog entry. Check it out for the full story...
</p>]]></description>
      <pubDate>Fri, 22 Dec 2006 07:14:01 -0600</pubDate>
    </item>
  </channel>
</rss>
