From MemberWiki

This page is intended to document,to compare and discuss the proposals and approaches (technologies, tools, frameworks) which have been described in publicly available literature to help build secure mashups.

Classification dimensions for mashups technologies

This section is an attempt to describe characteristics of mashup technologies as related in addressing security and function requirements of secure mashups. The characteristics should be, to the extent possible, value-free and factual and enable the comparison of the merits different approaches. The different dimensions and properties are distilled from use case scenarios and other general considerations and the various discussions.

We will refer to a self-contained client-side module contain business logic and potentially UI widgets as a component. This is in no way meant to revisit the multitude of component models which have come and gone. If you prefer not to use this term, replace it by the word gadget. When we use the word domain we mean the smallest units of code from which trust domains are formed. The idea of trust domains is indeed subjective and depends on whose perspective this is being seen from.

The following are some of the dimensions which different mashup security technologies can be compared on:

Isolation/Separation of components

Isolation can be performed on following resources

UI elements

DOM

Scripting language state

User-agent state

Backend communication

Mediated interaction

a. Is there a mechanism which allow mediation of interaction between components? More specifically,

b. Is there a built-in access control mechanisms. If so, what is the implied access control policy language; Who can decide on (what parts of) the policy?

c. Is there a well-identified entry point under full control of the component where a component can define its own policy? For the latter, what is the context information available to the component to identify, e.g., information about the caller?

Granularity of separation/mediation

a. Is it DNS same-domain, as mostly used today? What _exact_ same-domain policy is enforced?

b. Is there any support for more granular separation/isolation to better address least-privilege, which would mandate that even different code/components from the same server should be separable?

Supported communication scenarios

a. which of the following communication scenarios for client-side mashups are supported

(i). intra-domain client-side component to component communication

(ii). inter-domain (3rd-party) client-side component to component communication

(iii). intra-domain client-side component to server-side service communication

(iv). inter-domain (3rd-party) client-side component to server-side service communication

b. What type of communication is supported

(i) point-to-point

(ii) broadcast/multi-cast (events)

c. Are there restrictions in this communication, are there addressing or other restriction which restrict this communication to be between parent and child, an ancestor and descendants or is it allowed between arbitrary components. How is the naming issue solved?

Security & Trust

a. What are the implied trust assumption for this approach to work

b. What security guarantees does the communication provide

(i). authenticity/integrity

(ii). confidentiality

c. Does the approach protect against phishing or component hijacking?

Implementation issues

a. how complex is the development of secure mashups.

b. are the relevant policies easy to understand and intuitive to articulate? In particular, is the approach fail-safe (e.g., does granting of access work via opt-in as opposed to opt-out)?

c. what is the complexity of implementation the (enforcement) mechanism and the level of assurance we can get from it.

d. What is the performance impact

Applicability

a. Does the approach work with existing browsers out-of-the-box, and if so with all common ones?

b. If the approach requires browser modification, can it be implemented as plug-ins?

Standards & Endorsements

a. Are there any standards endorsing this approach

b. Other players endorsing that approach

Enforcement Landscape

There are a number of ways to approach this problem of enforcement in securing mashups. The following is a recap of some of the existing mechanisms for securing mashups as well as some proposals for extending current models to provide enforcement primitives for securing mashups.

Proposals based on existing browser features

To recap, the same-origin policy is the core of the current browser security model. It limits DOM access, XHR, and as well as server-state access such as cookies to places of same origin. It also allows some restricted broadening of rights as in domain-relaxation in javascript via document.properties or in cookies with wild-cards. A few issues about the same-origin policy are:

a. Hardly anything is standardized or even de-facto specified) and so, not surprisingly, behavior is not consistent. The concept of same-origin is slightly different for different resource. Also, for the same resource different browser implement it different. For example, most common definitions of origin includes all of protocol, host and port, some common browsers do NOT enforce isolation between content from two different ports of the same server.

b. Content from different domains in iframes are isolated from each other as in they are not allowed to access each other's DOM structure. In principle this also prevents them from communicating. However, a document and its child in a <iframe> can communicate with each other through several unadvertised means such as by modifying the fragment IDs in their source URLs. (see below how this can be leveraged to do secure mashups).

c. It does not really work for portal-like application with content coming from the same server. So in this case, one would have to force the content to come from different (virtual) servers such as by fixing the DNS etc.

d. The communication restrictions on XHR prevents natural access to 3rd-party services, leading to insecure practices such as JSONP. Using the classification dimensions we can rate the same-origin policy as

   (A) Isolation at least as far as UI elements/DOM is achieved via <iframe>s and browser state is isolated by the standard
       path/hostname mechanisms
   (B) Client components are allowed to talk to the server it came from. 
   (C) On the client-side intra-domain communication is clearly possible since components can look into each other's DOM elements  
   (D) Although inter domain communication is not supported officially there are mechanisms by which components can communicate 
       inter-domain. This is typically not mediated. 
   

In general, it is generally accepted that as it exists, it is insufficient to immediately satisfy the requirements for secure mashups. However, there are several frameworks which try to satisfy some or all of the security properties listed above have been developed around the isolation offered by this mechanism. Secure mashup models which use this the isolation provided by the same origin policy and augmented by various communication mechanisms include

Subspace

This approach has been discussed on both the security TF as well as the communication TF. See some discussion on the OAA mailing list at http://openajax.org/pipermail/security/2007q2/000032.html

As stated in the research paper primarily this is suggested as a mechanism by which one could enable cross-domain client to server communication. Thus it is not a true mashup framework but an enhancement of the same-origin security policy to allow a controlled cross-domain client to server communication. Note that even here that the domain-relaxation is possible to a common superdomain and hence cross-domain communication is limited to domains which are subdomains of a common superodmain. This approach can be used to put together mashups based on communication between the parent and a third-pary component using the child <iframe>. As noted this approach requires the third party service to run in the same address space as the mashup.

SMash

          (A) Isolation is achieved leveraging existing <iframe>s
          (B) Client-server communication via mechanisms is restricted to the same-origin policy.
          (C) Client side inter-domain communication is enabled in a mediated, policy-governed manner using the secure messaging hub
          (D) Can be extended to work with the browser extensions propsosed below.

XDDE

Some more esoteric proposals are:

Server-side analysis & instrumentation

BrowserShield

JavaScript Instrumentation for Browser Security

Proposals requiring browser modifications

There have been many proposals for browser extensions to address enforcement of security for mashups. The following are a few suggestions

The <module> tag

      <module id="NAME" src="URL" style="STYLE" />. 

Like an <iframe> a <module> is a unit of isolation i.e. contents on either side of a <module> boundary are isolated from each other. For communication across this boundary a module and the parent present to each other an interface consisting of two functions send and recieve which allows to the peer to send and recieve messages. This is a simple interface which as stated has the "main" page enabling cross-component cross-domain communication.

   (A) This is an extension of the <iframe> mechanism even for isolation in that it can be used to isolate components coming from 
       the same server as well those coming from multiple servers. So the granualrity of isolation is very fine.
   (B)  The communication interface between the parent and the child is somewhat simple and doesnt permit interaction between 
        arbitrary components, it doesnt solve issues of addressing component instances etc. It is perhaps best seen as an 
        enforcement primitive. Typically one would expect client side Javascript libraries to offer much richer communication 
        programming models.

MashupOS/<friv> tag/<ServiceInstances>

          (A) Addresses the isolation issue at a very fine granular level much like the <module> tag.
          (B) Cross-domain client to server communication is enabled using an abstraction similar to JSON-REQUEST described below. 
          (C) ServiceInstances can have named ports and any other domain can send a browser-side message to a named port using the 
              method INVOKE and specifying a local URL. 
          (D) The communication between client side components is NOT mediated and is left upto the receiving ServiceInstance to 
              decide whether to accept the message.

          (A) Note that unlike the <module> tag this doesnt provide a new isolation mechanism so same-origin components can 
              completely access each other internals
          (B) Doesnt provide a general addressing mechanism and as stated it appears to provide only parent-to-child addressing?