<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Luc Stepniewski&#039;s Blog &#187; wordpress</title>
	<atom:link href="http://www.gradstein.info/category/wordpress/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.gradstein.info</link>
	<description></description>
	<lastBuildDate>Thu, 29 Dec 2011 22:59:01 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<atom:link rel='hub' href='http://www.gradstein.info/?pushpress=hub'/>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
		<item>
		<title>Security patching WordPress themes against Cross-Script Attacks (XSS)</title>
		<link>http://www.gradstein.info/security/security-patching-wordpress-themes-against-cross-script-attacks-xss/</link>
		<comments>http://www.gradstein.info/security/security-patching-wordpress-themes-against-cross-script-attacks-xss/#comments</comments>
		<pubDate>Mon, 11 Jun 2007 21:27:02 +0000</pubDate>
		<dc:creator>Lior Gradstein</dc:creator>
				<category><![CDATA[security]]></category>
		<category><![CDATA[wordpress]]></category>

		<guid isPermaLink="false">http://www.gradstein.info/wordpress/security-patching-wordpress-themes-against-cross-script-attacks-xss/</guid>
		<description><![CDATA[A nice article explaining the vulnerability in Worpdress themes (in fact anything using php :-) was published some days ago. Now, there&#8217;s even a vulnerability scanner available (done in Perl). I ran it on several of the blogs I manage, and all of them were vulnerable to XSS (wp-scanner also tests other vulnerabilities) :-( I [...]]]></description>
			<content:encoded><![CDATA[<p><a href="/wp-content/uploads/wp_scanner.png" onclick="ps_imagemanager_popup(this.href,'WP Scanner','781','431');return false" onfocus="this.blur()" class="liimagelink"><img src="/wp-content/uploads/.thumbs/.wp_scanner.png" alt="WP Scanner" title="WP Scanner" align="right" width="96" height="53" border="0" /></a>A <a href="http://blogsecurity.net/wordpress/articles/article-070607/" class="liexternal">nice</a> article explaining the vulnerability in Worpdress themes (in fact anything using php :-) was published some days ago. Now, there&#8217;s even a <a href="http://blogsecurity.net/wordpress/tools/wp-scanner/" class="liexternal">vulnerability scanner available</a> (done in Perl).</p>
<p>I ran it on several of the blogs I manage, and <strong>all of them were vulnerable to XSS</strong> (wp-scanner also tests other vulnerabilities) :-(<br />
I followed the advices on blogsecurity&#8217;s website and modified all of the search functions I could find. Now wp-scanner doesn&#8217;t report any vulnerability (<em>it doesn&#8217;t mean it is cracker-proof, but it&#8217;s a good start</em>).</p>
<p>So if anybody else uses the <a href="http://www.deanjrobinson.com/wordpress/redoable" class="liexternal">Redoable theme</a> like me, you should patch the <code>header.php</code> file. Near the top of the file, find the <code>"Search for"</code> string, and enclose the <code>$s</code> string with the <code>htmlspecialchars()</code> method:</p>
<p class="code">Search for &lt;?php echo htmlspecialchars($s); }</p>
<p>Do the same for the <code>searchform.php</code> file:</p>
<p class="code">searchform&#8221; action=&#8221;&lt;?php echo htmlspecialchars($_SERVER['PHP_SELF']);</p>
<p>An even better protection would be to use the <a href="http://www.modsecurity.org/" class="liexternal">mod_security module</a> for Apache/Apache2, which can detect and block these kind of attacks. But this requires that you control your server.<br />
To prevent web visitors from sending tags, you can add the following rule in your virtual host:</p>
<p class="code">SecFilter &#8220;&lt;(.|\n)+&gt;&#8221;</p>
<p>Now, when someone requests &lt; anything &gt;, the visitor gets a 403 error, and in your audit log, you now have:</p>
<p class="code">==36d82a37==============================<br />
Request: www.gradstein.info 82.67.175.56 &#8211; - [11/Jun/2007:11:10:56 +0200] &#8220;GET /?s=%3Cwpscan%3E HTTP/1.1&#8243; 403 202 &#8220;-&#8221; &#8220;Mozilla/5.0&#8243; &#8211; &#8220;-&#8221;<br />
&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-<br />
GET /?s=%3Cwpscan%3E HTTP/1.1<br />
mod_security-message: Access denied with code 403. Pattern match &#8220;<(.|\\n)+>&#8221; at REQUEST_URI [severity "EMERGENCY"]<br />
mod_security-action: 403<br />
HTTP/1.1 403 Forbidden<br />
Content-Length: 202
</p>
<p class="information">Please note, that mod_security does not correct your application. Here if you only use mod_security, WordPress theme will still be vulnerable on the underlaying level. It is OK to use mod_security, but it is much much more advisable to correct the origin of the problem and not cover it.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.gradstein.info/security/security-patching-wordpress-themes-against-cross-script-attacks-xss/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
	</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using disk: basic
Page Caching using memcached

Served from: www.stepniewski.fr @ 2012-02-06 07:53:36 -->
