<?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>my 2 cents &#187; Internet security</title>
	<atom:link href="http://corneliusweiss.de/category/internet-security/feed/" rel="self" type="application/rss+xml" />
	<link>http://corneliusweiss.de</link>
	<description>Exciting brainjunk of Cornelius Weiss</description>
	<lastBuildDate>Sat, 24 Apr 2010 19:01:35 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Cross Site AJAX Window Name Proxy for extjs/ext-core</title>
		<link>http://corneliusweiss.de/2009/12/09/cross-site-ajax-window-name-proxy-for-extjsext-core/</link>
		<comments>http://corneliusweiss.de/2009/12/09/cross-site-ajax-window-name-proxy-for-extjsext-core/#comments</comments>
		<pubDate>Wed, 09 Dec 2009 08:56:44 +0000</pubDate>
		<dc:creator>Cornelius Weiss</dc:creator>
				<category><![CDATA[Internet security]]></category>
		<category><![CDATA[Javascript]]></category>
		<category><![CDATA[extJS]]></category>
		<category><![CDATA[tine 2.0]]></category>

		<guid isPermaLink="false">http://corneliusweiss.de/?p=222</guid>
		<description><![CDATA[Cross site communication in the browser using the XHTTPRequest Object is prohibited by the Same Domain Policy. With HTML 5 this restriction is relaxed within the so called workers.
As of now, normally the browser can only communicate with the domain the document being displayed comes from. As always, most restrictions can be circumvented somehow. Quite [...]]]></description>
			<content:encoded><![CDATA[<p>Cross site communication in the browser using the <a href="http://en.wikipedia.org/wiki/XMLHttpRequest">XHTTPRequest</a> Object is prohibited by the <a href="http://en.wikipedia.org/wiki/Same_origin_policy">Same Domain Policy</a>. With <a href="http://dev.w3.org/html5/spec/Overview.html">HTML 5</a> this restriction is relaxed within the so called <a href="http://www.whatwg.org/specs/web-workers/current-work/">workers</a>.</p>
<p>As of now, normally the browser can only communicate with the domain the document being displayed comes from. As always, most restrictions can be circumvented somehow. Quite a while now, the de facto standard approach for cross-site communication in the wild is <a href="http://en.wikipedia.org/wiki/JSON#JSONP">JSONP</a>.</p>
<p>In short: A javascript located at the foreign domain is inserted in background. Via the GET url parameters the data of the request is send. The script returned by the foreign server contains code which gets directly executed at include time of this script, e.g: callback({jsondata});</p>
<p>It is widely accepted that JSONP should be rated highly insecure for multiple reasons:<br />
- Including a script of a foreign domain is a build in XSS attack.<br />
- All parameters send to the foreign domain are part of the standard access logs of the foreign web servers.<br />
- &#8230;</p>
<p>A new idea for secure cross site communication <a href="http://www.sitepen.com/blog/2008/07/22/windowname-transport/">has come up</a> a year ago utilizes the fact, that the name property of browser windows/frames remains unchanged when a window/frame loads a new document even from a foreign domain. With this, it is possible to create a transport by inserting a hidden iframe which switches its document between the origin- and foreign domain.</p>
<p>This approach has the major advantage, that the data returned by the foreign domain is encoded as a string and could be evaluated in a safely. Moreover the request could be done via POST&#8217;s which solves EOI issues with server logs.</p>
<p>While I was aware of this new technique, I never had the need to do cross site request from the browser. In general my approach is to proxy data from foreign domains via the server as this gives a better control. However for a <a href="http://www.tine20.org/">Tine 2.0</a> related customer project I had the requirement to do cross site request from a website to a <a href="http://www.tine20.org/">Tine 2.0</a> installation directly from the browser.</p>
<p>Unfortunately I didn&#8217;t find any <a href="http://www.extjs.com/products/extjs/">extjs</a>/<a href="http://www.extjs.com/products/extcore/">ext-core</a> implementation of the window.name technique. Moreover I realized, that the implementation of other libraries always POST their request using form submits. But doing all request via form Submits would require an additional API for <a href="http://www.tine20.org/">Tine 2.0</a> as the standard JSON API talks <a href="http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal">JSONRPC</a>.</p>
<p>So what I needed was a XHTTPRequest/AJAX solution to be able to utilize the standard Tine 2.0 API&#8217;s. For this I created a windowNameConnection Proxy which based on ext-core does AJAX requests to the foreign domain. This sequence diagram visualizes it&#8217;s simple workings:<br />
<a href="http://corneliusweiss.de/wp-content/uploads/2009/12/windowNameConnectionDiagramm.png"><img src="http://corneliusweiss.de/wp-content/uploads/2009/12/windowNameConnectionDiagramm-300x156.png" alt="windowNameConnectionDiagramm" title="windowNameConnectionDiagramm" width="300" height="156" class="aligncenter size-medium wp-image-227" /></a></p>
<p>You can find the latest version of the implementation <a href="http://svn.tine20.org/svn/trunk/tine20/Tinebase/js/ux/data/">here</a>. The usage of this connection class is straight forward as it works like a normal extjs connection:</p>
<pre><code>
var connection = new Ext.ux.data.windowNameConnection({
    // this url is autodetected if windowNameConnection is loaded
    // from the foreign domain
    proxyUrl: https://foreign.domain/windowNameConnection.html
});

connection.request({
    url: https://foregin.domain/apiurl,
    header: {...}
    params: {...},
    success: someSuccessCb
});
</code></pre>
<p>Of course the ability to do AJAX requests is purchased by a minor performance loss compared to form posts. BUT: The windowNameProxy should only be seen as a fallback for Browsers which are not capable of the HTML5 workers. Users of these old browsers are obviously not keen on enhanced performance. Otherwise they would use an up to date browser.</p>
]]></content:encoded>
			<wfw:commentRss>http://corneliusweiss.de/2009/12/09/cross-site-ajax-window-name-proxy-for-extjsext-core/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Safari 3 solves AltName issue</title>
		<link>http://corneliusweiss.de/2007/11/19/safari-3-solves-altname-issue/</link>
		<comments>http://corneliusweiss.de/2007/11/19/safari-3-solves-altname-issue/#comments</comments>
		<pubDate>Mon, 19 Nov 2007 20:13:13 +0000</pubDate>
		<dc:creator>Cornelius Weiss</dc:creator>
				<category><![CDATA[Internet security]]></category>
		<category><![CDATA[my favorite fruit]]></category>
		<category><![CDATA[rootStuff]]></category>

		<guid isPermaLink="false">http://corneliusweiss.de/?p=38</guid>
		<description><![CDATA[TodayÂ Nils Toedtmann published a grave security issue. In Firefox, Konqueror and Opera an attacker could fake SSL secured sites.Thus, its possible that your browser shows a faked site https://mybank.com without a certificate warning.
The good news for Mac users is, that in Leopard and the latest updates to Tiger ( I just checked this), this problem [...]]]></description>
			<content:encoded><![CDATA[<p>TodayÂ <a href="http://nils.toedtmann.net/pub/subjectAltName.txt" target="_blank">Nils Toedtmann published a grave security issue</a>. In Firefox, Konqueror and Opera an attacker could fake SSL secured sites.Thus, its possible that your browser shows a faked site <code>https://mybank.com</code> without a certificate warning.</p>
<p>The good news for Mac users is, that in Leopard and the latest updates to Tiger ( I just checked this), this problem is resolved. However, with my old notebook (not updated, safari 2.0.0.9) this kind of attackers is possible.</p>
<p><a href="http://test.eonis.net/" target="_blank">Use this site</a>Â to check if your Bother isÂ vulnerable.</p>
]]></content:encoded>
			<wfw:commentRss>http://corneliusweiss.de/2007/11/19/safari-3-solves-altname-issue/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
