<?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: Firewall Makers vs Evil JavaScript</title>
	<link>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/</link>
	<description>Giorgio Maone's answers to the Web, the Universe, and Everything</description>
	<pubDate>Wed, 16 May 2012 21:59:02 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.3</generator>

	<item>
		<title>By: Giorgio</title>
		<link>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9268</link>
		<dc:creator>Giorgio</dc:creator>
		<pubDate>Sat, 13 Sep 2008 07:33:27 +0000</pubDate>
		<guid>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9268</guid>
		<description>@&lt;b&gt;Mook&lt;/b&gt;:
You're obviously right: that's much challenging (as I said) because you should manage to sandbox and analyze the page behaviour, isolating exploits so that they do not bring down the firewall/proxy itself (kind of virtualization?) 
Also this would't add anything to protect from &lt;em&gt;in-browser&lt;/em&gt; attacks such as XSS and CSRF, because (unless you add some technology which you could better deploy inside the browser itself, such as NoScript, Firekeeper, CSP or the upcoming ABE) they would be successfully carried by the proxy.
My whole point (and the conclusion of the original article as I understood it) is that securing JavaScript at the semantic level is very impractical, if not impossible, and anyway a task for the browser, not for any other external device/software.</description>
		<content:encoded><![CDATA[<p>@<b>Mook</b>:<br />
You&#8217;re obviously right: that&#8217;s much challenging (as I said) because you should manage to sandbox and analyze the page behaviour, isolating exploits so that they do not bring down the firewall/proxy itself (kind of virtualization?)<br />
Also this would&#8217;t add anything to protect from <em>in-browser</em> attacks such as XSS and CSRF, because (unless you add some technology which you could better deploy inside the browser itself, such as NoScript, Firekeeper, CSP or the upcoming ABE) they would be successfully carried by the proxy.<br />
My whole point (and the conclusion of the original article as I understood it) is that securing JavaScript at the semantic level is very impractical, if not impossible, and anyway a task for the browser, not for any other external device/software.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mook</title>
		<link>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9267</link>
		<dc:creator>Mook</dc:creator>
		<pubDate>Sat, 13 Sep 2008 05:05:01 +0000</pubDate>
		<guid>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9267</guid>
		<description>But if you manage to execute the script with the browser context anyway, isn't that just like actually being in the browser?  That is, you negate the security benefits by putting a different browser in front that can be exploited?  Especially if it's using the same JS engine (spidermonkey / V8)...</description>
		<content:encoded><![CDATA[<p>But if you manage to execute the script with the browser context anyway, isn&#8217;t that just like actually being in the browser?  That is, you negate the security benefits by putting a different browser in front that can be exploited?  Especially if it&#8217;s using the same JS engine (spidermonkey / V8)&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Giorgio</title>
		<link>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9265</link>
		<dc:creator>Giorgio</dc:creator>
		<pubDate>Fri, 12 Sep 2008 21:01:37 +0000</pubDate>
		<guid>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9265</guid>
		<description>@&lt;b&gt;Benjamin&lt;/b&gt;
ROTFL, that's why I talked about sandboxed &lt;em&gt;execution&lt;/em&gt;...</description>
		<content:encoded><![CDATA[<p>@<b>Benjamin</b><br />
ROTFL, that&#8217;s why I talked about sandboxed <em>execution</em>&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Benjamin Otte</title>
		<link>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9264</link>
		<dc:creator>Benjamin Otte</dc:creator>
		<pubDate>Fri, 12 Sep 2008 20:47:09 +0000</pubDate>
		<guid>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9264</guid>
		<description>Here's a program. if it inf-loops it's evil, if it doesn't it's fine. Now we just need to solve the halting problem and then we can secure JS!</description>
		<content:encoded><![CDATA[<p>Here&#8217;s a program. if it inf-loops it&#8217;s evil, if it doesn&#8217;t it&#8217;s fine. Now we just need to solve the halting problem and then we can secure JS!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Giorgio</title>
		<link>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9263</link>
		<dc:creator>Giorgio</dc:creator>
		<pubDate>Fri, 12 Sep 2008 19:32:06 +0000</pubDate>
		<guid>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9263</guid>
		<description>@&lt;b&gt;Doron&lt;/b&gt;:
Caja's scope is quite different, IMHO, trying to provide a sandboxed environment for web applications wanting to run user-generated JavaScript "safely".</description>
		<content:encoded><![CDATA[<p>@<b>Doron</b>:<br />
Caja&#8217;s scope is quite different, IMHO, trying to provide a sandboxed environment for web applications wanting to run user-generated JavaScript &#8220;safely&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Doron</title>
		<link>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9262</link>
		<dc:creator>Doron</dc:creator>
		<pubDate>Fri, 12 Sep 2008 19:22:50 +0000</pubDate>
		<guid>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9262</guid>
		<description>Google has a project called Caja (http://code.google.com/p/google-caja/) that attempts to secure javascript in webpages by rewriting it and allowing you to configure what the JS can access.</description>
		<content:encoded><![CDATA[<p>Google has a project called Caja (http://code.google.com/p/google-caja/) that attempts to secure javascript in webpages by rewriting it and allowing you to configure what the JS can access.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Giorgio</title>
		<link>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9261</link>
		<dc:creator>Giorgio</dc:creator>
		<pubDate>Fri, 12 Sep 2008 18:17:06 +0000</pubDate>
		<guid>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9261</guid>
		<description>@&lt;b&gt;Rob&lt;/b&gt;:
I can't tell for sure, but I tend to agree with your polite aesthetic judgment.</description>
		<content:encoded><![CDATA[<p>@<b>Rob</b>:<br />
I can&#8217;t tell for sure, but I tend to agree with your polite aesthetic judgment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob</title>
		<link>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9260</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Fri, 12 Sep 2008 18:14:11 +0000</pubDate>
		<guid>http://hackademix.net/2008/09/12/firewall-makers-vs-evil-javascript/#comment-9260</guid>
		<description>Hey, the &lt;a href="http://www.f5.com/images/home/home004.jpg" rel="nofollow"&gt;F5 girl&lt;/a&gt; is hot!
Is she Lori or a different model? :P</description>
		<content:encoded><![CDATA[<p>Hey, the <a href="http://www.f5.com/images/home/home004.jpg" rel="nofollow">F5 girl</a> is hot!<br />
Is she Lori or a different model? :P</p>
]]></content:encoded>
	</item>
</channel>
</rss>

