Tuesday, October 31st, 2006

Secure Ajax Mashups with the <module> tag

Category: Editorial

<p>Douglas Crockford had a great talk at the show last week surrounding JSON, and how we can get to a place where secure ajax mashups are possible.

Brent Ashley just posted about the situation:

Take XMLHttpRequest – calls are limited to the server where the current page originated. Can’t mash up without proxying through the server. Doesn’t scale well.

Take iframes – you can embed a page from another site, but due to Javascript same-domain restrictions, you cannot communicate with that page without some quite obtuse hackery on which you’d like to avoid relying.

Take the script tag – you can execute code from another site, however you have no opportunity whatsoever to inspect it for security before it gets executed, meaning there must be a lot of trust in the other end of the transaction and no hope of avoiding man-in-the-middle attacks. Using script tag methods, cross-site cookie access can cause privacy issues. Insecure, undesirable.

What we need is browser features that were designed with mashups in mind. We need them to be added to the browsers without having to wait until IE8 and Firefox 3 (…Safari 3, Opera 10, etc).

We have heard about JSON and JSONRequest, but the new kid on the block is a new html tag <module> that allows you to create secure zones from multiple sites on a single page with controlled communication between them.

Modules

I propose a new HTML tag for partitioning a page into a collection of modules.

<module id="NAME"
href="
URL" style="STYLE"
/>

A module has three attributes. The attributes are id, which is
used by scripts to gain access to the module node, href, which
is the url of either a script file or an HTML file, and style,
which is used to set the size and location of the module. (There may turn out
to be addition attributes.)

A module has two nodes. The outer node is exposed only to the outer document.
The inner node is the module’s window object. Scripts on one side
of the module barrier are unable to call scripts on the other side to to access
or modify the other side’s data structures or document structures. Communication
between the outer and inner nodes is permitted only using a send/receive mechanism.

We need to all get behind these proposals, get the process started, and really push for a new browser security module that let’s us take these applications to the next level. What do you think we need?

Related Content:

Posted by Dion Almaer at 8:20 am
14 Comments

+++--
3.3 rating from 23 votes

14 Comments »

Comments feed TrackBack URI

This is a very good concept and I would love to see this be developed by some of the browsers that are out there.

As you say IFrames although they do what they were designed to they give us very limited control over the content that will execute. Infact we are limited to visual control only.

I would like to put forward my support for this new in html!

Stuart Macfarlane
IT Support Analyst and Developer

Comment by Stuart Macfarlane — October 31, 2006

No need for this.
What we need is a format agnostic httprequest object with push/pull
Fix the three working ways we have today instead of adding more complexity to the mix

Comment by Veto — October 31, 2006

Moreover, extend the iFrame tag with a couple of attributes

origin=”local/external”
access=”full/restricted”

And please, never ever make it json only, that would be a costly mistake.

Comment by Veto — October 31, 2006

I don’t think this is a very good idea. If there’s a problem with how JS does something, fix JS. It doesn’t make sense to muck up a mark up language just to open security for JS/AJAX mashups. So far the best idea that’s been discussed has been the agnostic Http Request.

Comment by Andrew Herron — October 31, 2006

I’m a pessimist in this area. Cross-browser limitations are circumvented ‘enough’ to make surfing the web a dangerous thing for “average users” who have no idea about security. If there is a way to create a mashup on the client-side, chances are someone will exploit that. Imagine a bank phishing site that contains the *actual* bank website with a hidden frame (from another domain) logging keystrokes. Embedding with may be a possible answer, but if you think about it like a criminal, the possibilities become endless when the restrictions become less restrictive.

Comment by Jon — October 31, 2006

I think fixing JS would be the way to go. I vote for JS using crossdomain.xml. It seems to work for Flash just fine. I currently use Flash or <script> for my AJAX needs.

Comment by Phill Kenoyer — October 31, 2006

http://whatwg.org/specs/web-apps/current-work/#crossDocumentMessages

Comment by Dean Edwards — October 31, 2006

Making signed scripts a public standard, and letting users manage which scripts they trust seems a better solution than adding a new behavior to the browser.

Comment by ARWolff — October 31, 2006

The event flow between modules would almost certainly have to be accessible from JS, which would huge security holes. It would provide the means for simple cross-site scripting attacks. i concur with everyone else, fix the problem at hand, don’t create new ones.

Comment by Dan — October 31, 2006

Dean is right, this proposal seems is equivalent to the WHAT-WG cross-document messaging API.
The problem that I see with both is that the unit of isolation is still the iframe. But iframes cause trouble when it comes to making the UI elements flow, because their size is fixed.
Would there instead be a way to achieve both API isolation and cooperation, while keeping the good UI composition properties of existing HTML elements?

Comment by Julien Couvreur — October 31, 2006

What we need is a cross platform XHR call, one that doesn’t send cookies and such. Would cover all cases. Could perhaps include some extra header info so site that is called could refuse the call.

Comment by Berend de Boer — October 31, 2006

The encapsulation sounds rather reminiscent of IE’s old (now-deprecated) DHTML Scriptlets.

Comment by Rob — November 4, 2006

This subject was actually bouncing around in my head this wknd at the nfjs conference. I generally want to implement mashups in the client. The webtier mashup feels wrong to me (as does much of the ajax-generation and formatting commonly done in a fat webtier – but that’s another topic). I’d definitely like to see a solution that could safely allow me to interact with multiple domains via xmlhttp without opening up a whole new world of cross-site attacks. I need to think about this some more and better understand Crockford’s proposal, but in the meantime, 2 quick thoughts… 1. if we had a mature cross-browser javascript-signing mechanism in place, it would at least open this type of mashup in the trusted context.
2. instead of just flat out denying my xmlhttp.open(), the browser could give the use a chance to allow/deny. I know, it’s horrible, but it’s short-term hopefully and better than nothing, and it could remember your choices, and and those are all the excuses i gots.
cheers!!

Comment by scott ulrey — March 5, 2007

I like wolf’s idea about a script signing standard

Comment by justin — July 5, 2007

Leave a comment

You must be logged in to post a comment.