Garo Garabedyan's Divergent Thinking Blog

WWW like an Operating System. SOA in the presentation level

with one comment

I think that the presented down way of loading data from different domains is the right way of implementing SOA in the open architectured WWW. Making WWW as powerful as an Operating System.

Introduction on SOA, SameOrigin Policy, Cookies, Authentification practices and Ajax:

Since I have been a big fan of Ajax I was reading many stuff about how XMLHttpRequest is useful and what are its’ weak parts. I was unhappy to read some developers’ opinions about how they find SameOrigin Policy not allowing Ajax apps to be fully SOA and let JS to connect to different domains but only the source one. I think that SameOrigin has its purpose about the user and the policy behind the technology achieves it very well.

I find it useful to attach its’ cookies every time when a request is made to some domain.

Cookies are may be not the right technology to store session information, hidden fields are a better option. But there are some cases when session cookie is needed: user opens a page in many tabs and in this particular case it is not user-friendly to force him to re-enter its authentication data when he opens an URL not containing in itself the session information.

I share the decision of making XMLHttpRequest not able to connect to different domains, only execute and process requests to and from the source domain.

SOA is based on exchanging data between services. Service is a component of an application (possible and very good practice is a service to be used by many applications, which are unknown to the service) accessible trough a network connection (Internet too). It is possible and useful processing data from different sources by JS code executed in a browser.

I think that the next technique of loading data from different domains is the right way of implementing SOA in the open architectured WWW. You should let the other domain to do what he wants before to give you the requested data. The simple bean object (json implementation or whatever) is not a decision when transmit data to unknown apps in the web. Just let the other domain to be able to establish a direct connection with the user in order to ensure some security policies. Or even collecting some user’s information/ wishes and transmit them to the it’s domain in order to be calculated the main data which later to be passed to the first JS application.

Note: JavaScript no matter it’s SRC tag is thought to be part of the source domain of the web page, and SameOrigin Policy doesn’t allow this code to establish XMLHttpRequest to it’s SRC domain. Needed to be used again dynamic JS loading, but this time this loading script’s SRC to be non-guessable from the main JS application in order the letter to not bypass the public JS script and try to load the main data by itself and this way break the policy applied which the first dynamic loaded JS script tries to apply.

Technique allowing general like SOA between JS code executed in a browser and a servers on many and different domains:

I wanted to see an execution of SQL statements on stored data by Zoho Creator From Apps. So this is an example based on Zoho Creator execution of SQL statements through JS Api (this idea is still not implemented but Zoho promised me that they will add this to their feature list).

Request:
RequestURL: “http://zoho.com/app/sql.jsp?” + Session cookie pair (double cookie sending) + “&” + encrypted SQL request
Headers: all the cookies (with the session cookie in this count)
Response:
“zohoParser(” + JSON data + “);” or “[JS code which checks if user wants to allow this page to view the received data]; if ( [user wants and allows] ) { zohoParser(” + JSON data + “) }; ”

Scenario:
The client JS generates SQL encrypted request, writes a function called zohoParser which by a known array of parameters is supposed to present the received data to the main application and this way bypass Same-Origin Policy, adds to the body of the page: “<script src=”+ RequestURL +”>”, and waits until the data is received and then zohoParser called by the new loaded script with arguments- JSON data.

Used sources:
JSON security
http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniques-using.html
http://ajaxian.com/archives/gmail-csrf-security-flaw
Same-Origin Policy
http://taossa.com/index.php/2007/02/08/same-origin-policy/

Notes on vulnerabilities:
By rewriting some functions and methods from the JavaScript main libraries can be compromised the behavior of the scripts. Even more when they don’t know each other’s origin.

Future work on JS and browsers:
It is a new idea to program web browsers to treat every JS loaded script from its SRC domain. Providing its own script space in the web page and a way to declare public methods which are able to be accessed by this pattern: [domain].[publicFunction].(data); from the rest JS domains in the particular browser tab.
Main domain JSs can coordinate the execution of the scripts, their talks between each other (function callings between different domains scripts) and the access of the HTML body by locking some HTML roots and JS commands or by overwriting writing functions in order to apply some policy, which by default are parallel and without a restriction to access transmit data between themselves and the HTML body (DOM).
Main domain JSs can create new parallel scripts.
This way we can prevent any ill-intentioned overwriting of functions.

Conclusion:
I hope this technique will enable in one web page to be placed many and different data sources and this way make WWW as powerful as an Operating System.

Advertisements

Written by garabedyan

February 25, 2008 at 11:05

One Response

Subscribe to comments with RSS.

  1. […] WWW like an Operating System. SOA in the presentation level On this post, I have expressed an idea of using JavaScript Script Tag Hack (as Douglas Crockford calls it here: http://javascript.crockford.com/script.html) as a transport pack of data. I have added some additional thoughts about applying SameOrigin Policy to SRC attributes of SCRIPT tags and proving a document space to them which is the only XHTML content they can read/write. (one XHTML content can be read/write by scripts, but this JSs can’t access space beyond their defined). […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s