Better Security for Cross-site Scripts
Editing Better Security for Cross-site Scripts
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, 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.
Why Is This Important?
The implication of Cross-site scripts (XSS) is that it can be intentionally or unintentionally exploited for security breaches. The followings are a few examples:
- The cross-domain script can modify the DOM to display unintended information;
- The cross-domain script can monitor user input and steal sensitive data such as credit card number;
- The cross-domain script can steal cookies by sending all cookie issued by the originating server to some foreign server;
- 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 intentionally malicious or accidental damages.
Another XSS attack vector leverages the
innerHTML feature in browsers. If a public web site allows for HTML content to be uploaded, and that content were not filtered to remove
<script> tags, that when the content is retrieved, any embedded content
<script> tags would execute. (There are probably other attack vectors leveraging the
In these cases, it looks to the browser as if the script logic came from the same site as the original web page. To eliminate these attacks, browsers need some sort of mechanisms to identify trusted script logic versus untrusted script logic, plus a way to have trusted script logic prevent untrusted script log from executing.
- Using “iframe” as a security sandbox: This approach has been proposed by various entities. OpenAjax Hub 1.1 also leverages this technique to solve mashup security issues;
List of trusted sites?
At the OpenAjax F2F on 2008-03-21, there was a proposal that we could address XSS by providing a list of trusted sites:
To which there was a response:
<slightlyoff> ... well, that doesn't entirely solve it
Adobe AIR approach
Maybe this is a bad idea, but here goes nevertheless. How about if there is a new version of <meta> such as:
which provides a hidden key that only the originating web site could know (e.g., randomly generated with each session). The browser would parse/execute script logic that is included in the set of files that were listed before the load event is fired (the original application files therefore would have an implicit
and dynamically added event attributes could be preceded with a special function call:
<img src="..." onclick="withscriptkey(<number>);..." />
This is just a brainstorm. There are probably lots of complexities with the above proposal and probably other superior approaches.
Something very similar has been proposed by Gervase Markham (http://www.gerv.net/security/script-keys/).
Doug has also proposed a safe subset of ECMAScript (someone, please insert a link).
Mozilla's Site Security Policy
Background material that request this feature
- Cross-site Scripting on WikiPedia
- AdSafe by Douglas Crockford
- OpenAjax Hub 1.1 Proposal
- Possible Solutions to Web Security Issues (Coach Wei's summary of these few pages)
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 ===).
It is OK for others to insert comments within other people's sections, but as a courtesy please make sure that it is clear which part of the section is original and which section are annotative comments. For example, perhaps annotative comments would be colorized (e.g., enclosed by <span style="color:red">JON: Here is what I think about what you are saying.</span>).
Jon Ferraiolo comments
This is a complex issue, involving both browser complexities and security complexities. We want to make the Web more secure, but without breaking the existing Web, or making it a more secure web too complicated for mortals to use. The best exact solution probably will have to come from a comprehensive proposal from one of the browser vendors.
Kris Zyp's comments
The module tag could be recommended for browsers, but the exact behavior of such a mechanism would be incredibly complicated as it has a very wide vector for attacks, I am not sure if Doug is even still pursuing this one.
Douglas Crockford comments
Iframes are not currently a solution because of the top.location problem. If that could be corrected, then iframes with Cross Document Messaging could be used for safe mashups. This is something we should push on immediately.
Brad Neuberg comments
I'm not sure what the best technical mechanism is, but allowing for the following three use cases is important:
It seems like this proposal is related to having a better component or widget standard for the web as well. Caja is a good solution for sanitizing script as well and has come along nicely recently (disclosure: I work for Google, which has been developing Caja).
I don't really care what the exact technical solution is, though, as long as we get one that is good enough.
[Update] I'm confused -- does this proposal include better cross-domain mashups in general, or only isolating scripts from each other? If not, then we need a proposal for better cross-domain mashups that can be done securely, fast, and reliably.
Native JSON Parsing should be rolled into this, since native support for secure JSON parsing is instrumental to safer cross-site script security.
Nicole Tedesco's comments: implement a signed resource archiving solution
(From NicoleTedesco) A generalized resource bundling solution (images, sound files, XML and even other HTML pages) with digital signatures can provide an additional option to control trusted access to cross-site features, while also minimizing HTTP connection and overall bandwidth consumption. For details, see my comments in the Ajax Toolkit Caching discussion.
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.