<?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>Cupfighter.net &#187; Cross Site Scripting</title>
	<atom:link href="http://www.cupfighter.net/index.php/tag/cross-site-scripting/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.cupfighter.net</link>
	<description>A blog by Schuberg Philis colleagues</description>
	<lastBuildDate>Thu, 09 Feb 2012 14:27:59 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
		<item>
		<title>BlackHatEU : Universal XSS via IE8s XSS Filters</title>
		<link>http://www.cupfighter.net/index.php/2010/04/blackhateu-universal-xss-via-ie8s-xss-filters/</link>
		<comments>http://www.cupfighter.net/index.php/2010/04/blackhateu-universal-xss-via-ie8s-xss-filters/#comments</comments>
		<pubDate>Thu, 15 Apr 2010 14:35:08 +0000</pubDate>
		<dc:creator>Frank Breedijk</dc:creator>
				<category><![CDATA[BlackHatEU]]></category>
		<category><![CDATA[Conferences]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Barcelona]]></category>
		<category><![CDATA[Blackhat]]></category>
		<category><![CDATA[Conference]]></category>
		<category><![CDATA[Cross Site Scripting]]></category>
		<category><![CDATA[IE8]]></category>
		<category><![CDATA[Internet Explorer]]></category>
		<category><![CDATA[Microsoft]]></category>
		<category><![CDATA[XSS]]></category>

		<guid isPermaLink="false">http://www.cupfighter.net/?p=1009</guid>
		<description><![CDATA[By David Lindsay &#38; Eduardo Vela Nava The talk is about abusing the anti-XSS filters built into IE8 to always be able to perform XSS. Microsoft decided to implement anti-XSS measures in IE because XSS is so common. On the other hand the wanted to be careful not to break the web and to keep [...]]]></description>
			<content:encoded><![CDATA[<p>By David Lindsay &amp; Eduardo Vela Nava<a href="http://www.cupfighter.net/wp-content/uploads/2010/04/IE_logo.jpeg"><img class="alignright size-full wp-image-1020" title="Internet Explorer" src="http://www.cupfighter.net/wp-content/uploads/2010/04/IE_logo.jpeg" alt="Internet Explorer" width="116" height="116" /></a></p>
<p>The talk is about abusing the anti-XSS filters built into IE8 to always be able to perform XSS.</p>
<p>Microsoft decided to implement anti-XSS measures in IE because XSS is so common. On the other hand the wanted to be careful not to break the web and to keep things performant and the solution itself had to be secure.</p>
<p>So how do these filters work?<br />
•    Examine all outbound requests for XSS patterns using heuristics filters.<br />
•    If something matches the filter a dynamic signature is generated<br />
•    If the signature matches then the response is neutered.<br />
<span id="more-1009"></span><br />
The heuristic filters look for suspicious requests, e.g. parameters with &lt;script&gt; tags in them. The dynamic signature is then generated to take into account some forms of server transformations, but basically this looks if the same text is not returned as part of the web interface. If XSS is detected one character in the original text is replaced by a hash mark (#).</p>
<p>The presentation then gave a breakdown of typical heuristic signatures, they can all be found at http://p42.us/ie8xss/filters02.txt.</p>
<p>So one of the things the researchers found was that these filters can be bypassed. Regular expressions are not perfect and complex to write. Examples are at http://goo.gl/sour, and http://goo.gl/KVDI.</p>
<p>But even more fun is to turn the filters against themselves.</p>
<p>Because the filter is designed to filter out certain tags, it can be used to disable other script tags as well. This can be used to disable framebusters, block sandboxes and disable other javascript based security mechanism.</p>
<p>The XSS filters can also be used to alter the ‘=’ sign into a hash sign (#). Which can alter the entire meaning of certain HTML tags.</p>
<p>The XSS filters can be abused to malform (neuter) html tags. The onerror properties of these tagscan then be used to triggers scripts.</p>
<p>The way the XSS filter where built up allow the neutering of just about any = sign on a page.</p>
<p>So the attack has two stages: first you need to be able to insert text into an html name value pair. Then you need to trigger a fake XSS attack the will neuter the html name,value pair into activation.<br />
Is this common? Yes it is. Bing, Twitter, Wiki&#8217;s Social networks. About 99% of the sites that matter are vulnerable.</p>
<p>If you want to try out the attack yourself, use a vulnerable version of IE8 and visit http://0x.lv/attr.php</p>
<p>How was this fixed?<br />
Microsoft is no longer neutering the = sign</p>
<p>What can you do?<br />
* Turn XSS filtering off<br />
* Use a different browser<br />
* Upgrade you browser after Microsoft fixes it.</p>
<p>Should you disable the filters? No, benefit outways the risks.</p>
<p>What if I run a website?<br />
Microsoft allows websites to add a header that will opt you out of XSS filtering.<br />
&#8220;X-XSS-Protection: 0&#8243; or &#8220;X-XSS-Protection: 1; mode=block&#8221; which will not disable the protection, but will block the entire page from being rendered.</p>
<p>This issue was discovered and reported to Microsoft in September 2009 and was patch in Jauary 2010. Public disclosure was today.</p>
<p>So what about other browsers?<br />
Firefox: NoScript (good), NoXSS (don&#8217;t use)<br />
Webkit is developing XSSAuditor. It will respect the same control headers as IE8</p>
]]></content:encoded>
			<wfw:commentRss>http://www.cupfighter.net/index.php/2010/04/blackhateu-universal-xss-via-ie8s-xss-filters/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Mozilla&#8217;s case for Content Security Policies</title>
		<link>http://www.cupfighter.net/index.php/2009/07/mozillas-case-for-content-security-policies/</link>
		<comments>http://www.cupfighter.net/index.php/2009/07/mozillas-case-for-content-security-policies/#comments</comments>
		<pubDate>Thu, 02 Jul 2009 11:28:50 +0000</pubDate>
		<dc:creator>Frank Breedijk</dc:creator>
				<category><![CDATA[Security]]></category>
		<category><![CDATA[Cross Site Scripting]]></category>
		<category><![CDATA[Mozilla]]></category>
		<category><![CDATA[Web 2.0]]></category>

		<guid isPermaLink="false">http://www.cupfighter.net/?p=315</guid>
		<description><![CDATA[Mozilla makes a case for COntent Security Policies because the can completly kill Cross Site Scripting]]></description>
			<content:encoded><![CDATA[<p>In <a title="Mozilla Content Security Policy post" href="http://blog.mozilla.com/security/2009/06/19/shutting-down-xss-with-content-security-policy/" target="_blank">this post from 19-6 </a>Mozilla make a clear case for supporting content security policies.</p>
<p>A content security policy, <a title="Content Security Policy specification" href="https://wiki.mozilla.org/Security/CSP/Spec" target="_blank">which is specified here</a>, can impose common sense security restrictions on the (active) content of site.</p>
<p>A content security policy can completely kill Cross Site Scripting if it is set to:</p>
<ol>
<li>Require that all javascript is loaded from an external file</li>
<li>This file resides at a specified location</li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://www.cupfighter.net/index.php/2009/07/mozillas-case-for-content-security-policies/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

