Mashup security
From RuntimeWiki
NOTE: This feature has been moved to the inactive list. Two reasons for moving this to inactive: (1) The various requests around IFrame improvements overlap this one, (2) One of the specific requests contained within this feature, postMessage(), is already being addressed by the various browsers.
Contents |
Title
Mashup security
Detailed write-up
Description
Mashups mix and merge “mashup widgets” (data and code) from multiple sources in a user’s browser, to provide high-value web applications. Depending on how page authors assemble the mashup page, these widgets on the page may have unwanted access to the state of other widgets and the page. The issues of cross-site scripting and XSRF are even more proven to create major security holes in Mashups.
Why Is This Important?
Security is critical. If users do not feel that the Web in general is secure, they won't use it. Regarding mashups, if the world sees security problems with mashups, then that technology area might fail, and maybe harm the Web in general if it is impossible to distinguish non-mashup web pages from mashup web pages.
Possible Workarounds
- OpenAjax Hub 1.1 (http://www.openajax.org/member/wiki/OpenAjax_Hub_1.1_Specification_Managed_Hub_APIs) from OpenAjax Alliance. Note that Hub 1.1 defines a high-level abstraction layer that probably would allow it to leverage any advances in the area that are implemented natively within future browsers. Strongly suggest that browser vendors understand Hub 1.1 architecture before attempting to improve browsers in this area.
Background material that request this feature
- OpenAjax Hub 1.1 Proposal
- Possible Solutions to Web Security Issues (Coach Wei's summary of these few pages)
Discussion
In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section (e.g., === Jon Ferraiolo Comments ===).
Jon Ferraiolo Comments
I'm going to blow on the OpenAjax horn a bit here. We are hard at work trying to help the industry realize the revolutionary potential of mashups, but within the context of a robust security framework. The centerpiece of our efforts is OpenAjax Hub 1.1, which provides mashup containers with the ability to isolate untrusted 3rd party components. (Isolation usually means putting the component into an IFRAME that is in a different domain or sub-domain such that the browser will not allow that IFRAME to communicate or do JavaScript bridging with other IFRAMEs or the main mashup application.)
Isolation is great, but you don't have a mashup unless the widgets can pass messages to each other. For example, if the user selects a restaurant in a search widget, you might want a mapping widget within the same mashup to zoom into the location of the that restaurant. With Hub 1.1, there are various techniques for passing messages through a secure message mediation authority. One of the technical tricks for accomplishing this in Hub 1.1 is to pass messages through the window.location fragment identifier (aka HTTP proxy or FIM), which is a very ugly hack with some significant performance constraints on large size messages.
Therefore, from a Hub 1.1 perspective, we think we have security in hand, but what we need is better cross-frame messaging, where the cross-frame messaging facility aligns with the ability of the mashup application to intercept all cross-frame messages and institute its access control logic before messages are dispatched to other frames. We are pretty sure that HTML5's cross-frame messaging feature and Google Gears are both good technologies for this. Therefore, from an OpenAjax Hub 1.1 perspective, just give us HTML5 cross-frame messaging or Google Gears.
Phase I Voting - Vote for Your Top 5 Features
NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:
Phase II Voting
More about this later.
