<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Site Security Policy, AKA Content Restrictions</title>
	<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/</link>
	<description>Giorgio Maone's answers to the Web, the Universe, and Everything</description>
	<pubDate>Mon, 15 Mar 2010 20:32:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.3</generator>

	<item>
		<title>By: hackademix.net » NoScript's Anti-XSS Filters Partially Ported to IE8</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8481</link>
		<dc:creator>hackademix.net » NoScript's Anti-XSS Filters Partially Ported to IE8</dc:creator>
		<pubDate>Thu, 03 Jul 2008 10:05:52 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8481</guid>
		<description>[...] that post, calling for adoption of his own bright Content Restrictions idea, he forgot to say that one (experimental) implementation already exists… Do these cross-site scripting filters suppress legitimate cross-site references as well? [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] that post, calling for adoption of his own bright Content Restrictions idea, he forgot to say that one (experimental) implementation already exists… Do these cross-site scripting filters suppress legitimate cross-site references as well? [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: hackademix.net » Replace What?!</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8323</link>
		<dc:creator>hackademix.net » Replace What?!</dc:creator>
		<pubDate>Sat, 21 Jun 2008 10:05:23 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8323</guid>
		<description>[...] anybody know what this XeroBank guy is talking about? SPP can’t obviously stand for Site Pecurity Policy. It wouldn’t make sense (spelling and grammar aside) because SSP is not meant and not going [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] anybody know what this XeroBank guy is talking about? SPP can’t obviously stand for Site Pecurity Policy. It wouldn’t make sense (spelling and grammar aside) because SSP is not meant and not going [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Giorgio</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8213</link>
		<dc:creator>Giorgio</dc:creator>
		<pubDate>Tue, 10 Jun 2008 16:05:39 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8213</guid>
		<description>@&lt;b&gt;alanjstr&lt;/b&gt;:
First of all, how long, nice to have you back :)
1) It depends on how fast the SSP experimentation with its own extension goes. It would make some sense, though, because NoScript users would be probably willing to experiment with this stuff.
2) It's quite unlikely: SSP is the most a browser can do without appearing "rude" to web site owners. Blacklist-based adblocking is more likely to be built in a browser than whitelist-based script control.</description>
		<content:encoded><![CDATA[<p>@<b>alanjstr</b>:<br />
First of all, how long, nice to have you back :)<br />
1) It depends on how fast the SSP experimentation with its own extension goes. It would make some sense, though, because NoScript users would be probably willing to experiment with this stuff.<br />
2) It&#8217;s quite unlikely: SSP is the most a browser can do without appearing &#8220;rude&#8221; to web site owners. Blacklist-based adblocking is more likely to be built in a browser than whitelist-based script control.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: alanjstr</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8212</link>
		<dc:creator>alanjstr</dc:creator>
		<pubDate>Tue, 10 Jun 2008 13:30:42 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8212</guid>
		<description>1) So does this mean you're going to be incorporating SSP into NoScript until it becomes baked into the browser?  
2) Are you working to get some of the NoScript protections baked into the browser so that people don't have to always get an addon?</description>
		<content:encoded><![CDATA[<p>1) So does this mean you&#8217;re going to be incorporating SSP into NoScript until it becomes baked into the browser?<br />
2) Are you working to get some of the NoScript protections baked into the browser so that people don&#8217;t have to always get an addon?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Giorgio</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8197</link>
		<dc:creator>Giorgio</dc:creator>
		<pubDate>Mon, 09 Jun 2008 10:37:55 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8197</guid>
		<description>@&lt;b&gt;kuza55&lt;/b&gt;:
Thanks, I did not mean to talk about any "generic" verb tampering initiated from an user-agent in direct control of the attacker, who would obviously bypass any client-side restriction.
What I was hinting is that, since X-SSP headers allows administrator to declare HTTP verb restrictions, they could be used to enforce a default-deny policy for unused verb so that they could not be used &lt;em&gt;in the context of a CSRF attack&lt;/em&gt;.
I'll update the post accordingly.</description>
		<content:encoded><![CDATA[<p>@<b>kuza55</b>:<br />
Thanks, I did not mean to talk about any &#8220;generic&#8221; verb tampering initiated from an user-agent in direct control of the attacker, who would obviously bypass any client-side restriction.<br />
What I was hinting is that, since X-SSP headers allows administrator to declare HTTP verb restrictions, they could be used to enforce a default-deny policy for unused verb so that they could not be used <em>in the context of a CSRF attack</em>.<br />
I&#8217;ll update the post accordingly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kuza55</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8196</link>
		<dc:creator>kuza55</dc:creator>
		<pubDate>Mon, 09 Jun 2008 10:23:07 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8196</guid>
		<description>&#34;mitigating verb-tampering attacks&#34; - wait, what?
How are you proposing that client-side controls will mitigate server-side issues?</description>
		<content:encoded><![CDATA[<p>&quot;mitigating verb-tampering attacks&quot; - wait, what?<br />
How are you proposing that client-side controls will mitigate server-side issues?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Giorgio</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8174</link>
		<dc:creator>Giorgio</dc:creator>
		<pubDate>Sun, 08 Jun 2008 09:44:27 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8174</guid>
		<description>@&lt;b&gt;Gordon Mohr&lt;/b&gt;:
&lt;blockquote&gt;
Would X-SSP-Script-Source prevent people from inserting their own third-party or offsite scripts into sites? (As might happen via a bookmarklet or add-on.)
&lt;/blockquote&gt;
It will depend on the final implementation, I guess, since it's out of the scope of the current specification.
Giving users a chance to override SSP in cases like this is probably desirable, but I'm afraid it may not be technically trivial.
&lt;blockquote&gt;
Would X-SSP-Request-Source be usable by sites which don’t want any deep-linking, replacing the referrer-based blocks they now sometimes put in place?
&lt;/blockquote&gt;
Yes, of course, but I'm not sure there would be a great gain: you would still face fallback issues with not compliant or SSP-disabled browsers, as you currently do with anonymous or spoofed referrers.
But maybe SSP-compliance would be easier than reliable referrers to be required from your users "for their own good" ;)</description>
		<content:encoded><![CDATA[<p>@<b>Gordon Mohr</b>:</p>
<blockquote><p>
Would X-SSP-Script-Source prevent people from inserting their own third-party or offsite scripts into sites? (As might happen via a bookmarklet or add-on.)
</p></blockquote>
<p>It will depend on the final implementation, I guess, since it&#8217;s out of the scope of the current specification.<br />
Giving users a chance to override SSP in cases like this is probably desirable, but I&#8217;m afraid it may not be technically trivial.</p>
<blockquote><p>
Would X-SSP-Request-Source be usable by sites which don’t want any deep-linking, replacing the referrer-based blocks they now sometimes put in place?
</p></blockquote>
<p>Yes, of course, but I&#8217;m not sure there would be a great gain: you would still face fallback issues with not compliant or SSP-disabled browsers, as you currently do with anonymous or spoofed referrers.<br />
But maybe SSP-compliance would be easier than reliable referrers to be required from your users &#8220;for their own good&#8221; ;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gordon Mohr</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8168</link>
		<dc:creator>Gordon Mohr</dc:creator>
		<pubDate>Sun, 08 Jun 2008 00:05:25 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8168</guid>
		<description>Would X-SSP-Script-Source prevent people from inserting their own third-party or offsite scripts into sites? (As might happen via a bookmarklet or add-on.)

Would X-SSP-Request-Source be usable by sites which don't want any deep-linking, replacing the referrer-based blocks they now sometimes put in place?</description>
		<content:encoded><![CDATA[<p>Would X-SSP-Script-Source prevent people from inserting their own third-party or offsite scripts into sites? (As might happen via a bookmarklet or add-on.)</p>
<p>Would X-SSP-Request-Source be usable by sites which don&#8217;t want any deep-linking, replacing the referrer-based blocks they now sometimes put in place?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Giorgio</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8155</link>
		<dc:creator>Giorgio</dc:creator>
		<pubDate>Fri, 06 Jun 2008 13:12:40 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8155</guid>
		<description>@&lt;b&gt;Gareth&lt;/b&gt;:

I'm more for pushing it as a "shame on you" soft requirement for "serious" web applications (through some 3&lt;sup&gt;rd&lt;/sup&gt; party "validation" badge like you suggest) than a general browser-enforced requirement for all web sites (even the read-only ones), many of which actually &lt;em&gt;value&lt;/em&gt; inbound and outbound links very much (directories, search engines, blogs), and even liberal application-level relationships (mashup APIs anyone?)</description>
		<content:encoded><![CDATA[<p>@<b>Gareth</b>:</p>
<p>I&#8217;m more for pushing it as a &#8220;shame on you&#8221; soft requirement for &#8220;serious&#8221; web applications (through some 3<sup>rd</sup> party &#8220;validation&#8221; badge like you suggest) than a general browser-enforced requirement for all web sites (even the read-only ones), many of which actually <em>value</em> inbound and outbound links very much (directories, search engines, blogs), and even liberal application-level relationships (mashup APIs anyone?)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gareth Heyes</title>
		<link>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8154</link>
		<dc:creator>Gareth Heyes</dc:creator>
		<pubDate>Fri, 06 Jun 2008 12:39:39 +0000</pubDate>
		<guid>http://hackademix.net/2008/06/05/site-security-policy-aka-content-restrictions/#comment-8154</guid>
		<description>@Giorgio

Yep that's the only way to enforce the change as far as I can see it, otherwise we have security researchers and banks with well implemented security restrictions and everyone else with the same problem we have today. It will break the web, users will be annoyed but at the same time it would be a fundamental shift in internet security. If we force deny all it could work, if not then I can see another PGP situation (great technology but the majority don't implement it)

Noscript is a fantastic program but I feel it shouldn't be needed and like you say the servers should become the Noscript of the internet. 

A idea to smooth this transition would be to start requiring sites to have a crossdomain policy within the W3C validation, as web designers are already used to validating for XHTML , why not include the security policy in there as well?</description>
		<content:encoded><![CDATA[<p>@Giorgio</p>
<p>Yep that&#8217;s the only way to enforce the change as far as I can see it, otherwise we have security researchers and banks with well implemented security restrictions and everyone else with the same problem we have today. It will break the web, users will be annoyed but at the same time it would be a fundamental shift in internet security. If we force deny all it could work, if not then I can see another PGP situation (great technology but the majority don&#8217;t implement it)</p>
<p>Noscript is a fantastic program but I feel it shouldn&#8217;t be needed and like you say the servers should become the Noscript of the internet. </p>
<p>A idea to smooth this transition would be to start requiring sites to have a crossdomain policy within the W3C validation, as web designers are already used to validating for XHTML , why not include the security policy in there as well?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
