Coach Wei's Blog

The “Same Origin Policy” is at the core of browser’s security model.  Under the “Same Origin Policy”, a web resource can only interact with another web resource if and only if both resources are from the same origin. However, “Cross site scripting” and “cookie” both brings security challenges in this security model.

“Cross site scripting”
However, there is a notable exception to this rule. The “Same Origin Policy” does not apply to scripts and thus enables something typically called “cross site scripting (XSS)”. With XSS, a web page from one origin can contain a script element from a different origin. More importantly, this “foreign script” element has full access to everything else on this web page. Namely, the cross-domain script runs with the same authority as scripts from the originating domain.  As a result, XSS can be intentionally or unintentionally exploited for security breaches.

“Cookie”
All browsers support “cookie” which allows web applications to store a small amount of data on the client side. When a browser sends a request to a server, cookies issued by this server are always sent back as part of the request.  A lot of web applications store stateful information using “cookies”. Not uncommonly, cookies can contain security sensitive information.

As a result of “same domain policy”, a server does not have access to cookies issued by other servers, which is good. However, given that browsers always send cookies back to the server as part of every request, this “trust” relationship between client side “cookies” and server side state can be exploited for security breaches.

As a result, the current security model manifests itself into the following problems:

1. Lack of security sandbox for cross site scripts makes it difficult to enforce proper security measure for cross site scripts
2. “Same Origin Policy” does not fulfill legitimate use cases of accessing data from different servers
3. “Cross site request forgery” that exploits the simplistic “trust” relationship between client side cookie and server side state  by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have authenticated, for example.
4. Mashups, most of which are based on cross-site scripting, have significant security concerns

1. Need a Security Sandbox for Cross-site Scripts

The implication of XSS is that it can be intentionally or unintentionally exploited for security breaches. The followings are a few examples:

1. The cross-domain script can modify the DOM to display unintended information.
2. The cross-domain script can monitor user input and steal sensitive data such as credit card number.
3.  The cross-domain script can steal cookies by sending all cookie issued by the originating server to some foreign server.
4. The cross-domain script can send background requests directly to the originating server to conduct ill-intended operations.

Reference 1 (http://en.wikipedia.org/wiki/Cross-site_scripting) has some detailed description of XSS and its problems.

At the core of XSS problem is the lack of any security “sandbox” for cross-domain scripts. Cross-domain scripting is powerful and enables a lot of services that web users enjoy (for example, GoogleMap widget), the lack of any security sandbox for cross-domain scripts makes any websites that use such technique highly vulnerable, resulting either malicious or accidental damages.

Possible Solutions:

1. ADSafe (http://www.adsafe.org/): ADsafe defines a subset of JavaScript that is powerful enough to allow guest code to perform valuable interactions, while at the same time preventing malicious or accidental damage or intrusion.
2. Using “iframe” as a security sandbox: This approach has been proposed by various entities, such as SMash. OpenAjax Hub 1.1 also leverages this technique to solve mashup security issues.

2. Stronger Cross-site Request Forgery Protection

Reference http://www.owasp.org/index.php/Cross-Site_Request_Forgery  described XSRF problem well: Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.

Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

Possible Solutions:

In general, I have not seen enough attention given to XSRF. The best way to prevent XSRF is to handle it on the server side and avoid storing sensitive information on the client side cookies. Some of the attempts to make cookie less vulnerable are:

1. Adding “httpOnly” cookie attribute: Internet Explorer adds a cookie attribute called “httpOnly” that cookies with such attribute are not accessible from scripts. Unfortunately other browsers do not support this. “httpOnly” makes web site less vulnerable from XSS, see reference

2. Joe Walker (see reference http://getahead.org/blog/joe/2007/08/07/fixing_browser_security_samerefereronly.html) proposed adding “sameRefererOnly” attribute to cookies so that such cookies will only be sent back to a server if the referring web page is from this server.  “sameRefererOnly” will help make cookies more secure, and make it harder to carry out XSRF.

3. Access data from different servers

Though “Same Origin Policy” allows cross-site scripting, it does not allow web applications accessing data on other servers. The next generation of web applications will be much more data intensive. They will want to exchange data with other servers than the originating server. There is no other way of achieving this except for exploiting the above “cross site scripting” loophole. In fact, the so called “Mashup” phenomenon like how people typically embed GoogleMap into their own web pages relies on this technique, leaving many web applications under significant security risks.

Possible Solutions:

1. JSONRequest, as proposed in reference http://json.org/JSONRequest.html

2. Cross-domain Request (XDR), XDomainRequest, built into IE8 (http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/Dev...)

4. Mashup security

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.

 In order to properly isolate these widgets from each other to prevent unwanted access, page authors can load each widget into its own “iframe”. For example, IBM researchers proposed “SMash” that uses iframe to isolate different widgets.  However, due to the lack of cross frame communication mechanism, interaction between widgets is not possible. “Smash” uses <iframe>s to maintain isolation between components from different domains and to use the fragment ID of the URLs to enable communication between the frames, which is “hack” though it works on browsers. What would be ideal here is to have the “iframe” isolation and a high level secure messaging mechanism among the iframes without breaking the “same origin” policy.

Possible Solutions:

1. OpenAjax Hub 1.1 (http://www.openajax.org/member/wiki/OpenAjax_Hub_1.1_Specification_Managed_Hub_APIs) from OpenAjax Alliance.

References

• Why Do 'Cool Kids' Choose Ruby or PHP to Build Websites Instead of Java?
• Exclusive Q&A with Coach Wei - Chairman, Founder & CTO of Nexaweb
• Coach Wei Explains Enterprise AJAX Adoption Without Being a Rocket Scientist