Chester Clinic

 

Ccsl.carleton.ca

SOMA: Mutual Approval for Included Content in Web Pages
Terri Oda Glenn Wurster P. C. van Oorschot Anil Somayaji Carleton Computer Security Lab School of Computer Science Carleton University, Canada {toda, gwurster, paulv, soma}@scs.carleton.ca untrusted, untrustworthy, or even malicious. Such malicious inclu- Unrestricted information flows are a key security weakness of cur- sions can initiate drive-by downloads [26], misuse a user's creden- rent web design. Cross-site scripting, cross-site request forgery, tials [13], or even cause distributed denial-of-service attacks [21].
and other attacks typically require that information be sent or re- One common thread in these scenarios is that the browser must trieved from arbitrary, often malicious, web servers. In this paper communicate with web servers that normally wouldn't be contacted.
Those servers may be controlled by an attacker, may be victims, Same Origin Mutual Approval (SOMA), a new pol- icy for controlling information flows that prevents common web or may be unwitting participants; whatever the case, information vulnerabilities. By requiring site operators to specify approved ex- should not be flowing between the user's browser and these sites.
ternal domains for sending or receiving information, and by requir- In this paper, we propose a policy for constraining communica- ing those external domains to also approve interactions, we prevent tions and inclusions in web pages. This policy, which we call Same page content from being retrieved from malicious servers and sensi- Origin Mutual Approval (SOMA), requires the browser to check tive information from being communicated to an attacker. SOMA that both the site operator of the page and the third party content is compatible with current web applications and is incrementally provider approve of the inclusion before any communication is al- deployable, providing immediate benefits for clients and servers lowed (including adding anything to a page). This "tightening" that implement it. SOMA has an overhead of one additional HTTP of same origin policy prevents attackers from loading malicious request per domain accessed and can be implemented with minimal content from arbitrary web sites and restricts their ability to com- effort by application and web browser developers. To evaluate our municate sensitive information. While attacks such as cross-site proposal, we have developed a Firefox SOMA add-on.
scripting are still possible, with SOMA they must be mounted fromdomains trusted by the originating domain. Because attackers havemuch less control over this small subset than they do over other ar-bitrary hosts on the Internet, SOMA can prevent the exploitation of Categories and Subject Descriptors
a wide range of vulnerabilities in web applications.
C.2 [General]: Security and protection; H.3 [Online Information
In addition to being effective, SOMA is also a practical proposal.
Services]: Web-based services
To participate in SOMA, browsers have to make minimal codechanges and web sites must create small, simple policy files. Sites and browsers participating in SOMA can see benefits immediately,while non-participating sites and browsers continue to function as normal. These characteristics facilitate incremental deployment,something that is essential for any change to Internet infrastructure.
We have implemented SOMA as an add-on for Mozilla Firefox 2 and 3, which can be run in any regular installation of the Firefox web security, JavaScript, same origin policy, cross-site scripting browser. In testing with this browser and simulated SOMA policy (XSS), cross-site request forgery (XSRF) files for over 500 main pages on different sites, we have found nocompatibility issues with current web sites. The policy files for these sites have been, with only a few exceptions, extremely easy Current web pages are more than collections of static informa- to create and cause no compatibility issues. Simulated attacks are tion: they are a synthesis of code and data often provided by multi- also appropriately blocked. To retrieve policy files, SOMA requires ple sources that are assembled and run in the browser. Users gener- an extra web request per new domain visited. As we explain in ally trust the web sites they visit; however, external content may be Section 5, such overhead is minimal in practise. For these reasons,we argue that SOMA is a practical, easy to adopt, and effectiveproposal for improving the security of the modern web.
The remainder of this paper proceeds as follows. Section 2 gives background on current web security rules and attacks on modernweb pages. Section 3 details the proposed Same Origin Mutual Ap- ACM, 2008. This is the author's version of the work. It is posted here proval design, which we then evaluate in Section 4. Our prototype by permission of ACM for your personal use. Not for redistribution. The and the results of testing in the browser are described in Section 5.
definitive version was published in Proceedings of 15th ACM Conference We discuss some alternative browser security proposals and other on Computer and Communications Security.
CCS'08, October 27–31, 2008, Alexandria, Virginia, USA.
related work in Section 6. Section 7 concludes.
Copyright 2008 ACM 978-1-59593-810-7/08/10 .$5.00.
scripts are then loaded into the page, and also gain read and modify access to any content coming from the origin.
A page creator could choose to include content only from sources they deem trustworthy, but this does not mean that all content in- cluded will be directly from those sources. Any script loaded from a "trustworthy" domain can subsequently load content from any domain. Unfortunately, trust is not transitive, even if JavaScripttreats it that way. Besides the risk of an intentionally malicious Table 1: Current JavaScript access to other content (permis-
script loading additional, dangerous code, there is also the risk of sions denoted SO are dictated by the Same Origin Policy)
a "trustworthy" domain inadvertently loading malicious content.
Even well-known, legitimate advertising services have been trickedinto distributing malicious code [32, 28].
BACKGROUND AND MOTIVATION
Unrestricted outbound communication
Web browsers are programs that regularly engage in extensive cross-domain communication. In the course of a user viewing a While the same origin policy restricts how content from another web page, they will retrieve images from one server, advertisements domain can be used, it does not stop any content from other do- from another, and post a user's responses to a third. In this way the mains from being requested and loaded into the origin page. These browser serves as a dynamic, cross-domain communications nexus.
requests for content can be abused to send information out to any While such promiscuity may be permissible when combining static arbitrary domain.
data, to maintain security, restrictions must be placed upon exe- One common JavaScript attack involves cookie-stealing.1 A script cutable content.
reads cookie information from the user's browser and uses it as part JavaScript has two main security features that limit the potential of the URL of a request. An innocuous request, such as an extra damage of malicious scripts: the sandbox and the same origin pol- image, may actually be used to send data to attacker.com: icy. Assuming there are no bugs in the implementation, the sand- var image = new Image(); box prevents JavaScript code from affecting the underlying system or other web browser instances (including other tabs). Each page is contained within its own sandbox instance. The same origin pol-icy [31] helps to define what can be manipulated within this sand- Such cookie information could then be used by the remote server box and how sandboxed code can communicate with the outside to gain access to the user's session, or to get other information about world. The same origin policy is designed to prevent documents or the user. Any information that can be read from the document could scripts loaded from one "origin" from getting, or setting properties be sent out in a similar manner, including credit card information, of, content loaded from a different origin (with a special case in- personal emails, or username and password pairs. Even if a user volving subdomains). The origin is defined as the protocol, port, does not hit "submit" on a form, any information they enter can be and host from which the content originated. While scripts from read by JavaScript and potentially retransmitted.
different origins are not allowed to access each other's source, thefunctions in one script can be called from another script in the same Cross-site request forgery (XSRF/CSRF)
page even if the two scripts are from different domains. JavaScript The information theft techniques described in the previous sec- code has different access restrictions depending on the type of con- tion can be used to launch a cross-site request forgery (XSRF or tent being loaded. For example, it can fetch (make a request for) CSRF) attack [3]. Some URLs, when requested, cause an action to HTML, but it can only read and modify the information it gets as a be performed on the web server: a message is posted, a friend is result if the HTML falls within the same origin. These restrictions added, a vote is cast. Providing easy links for these actions is very are summarized in Table 1.
useful for the web developer who may want to include them in a Any script included onto a page inherits the origin of that page.
menu or elsewhere on the page. What happens, however, if one of This means that if a page from http://example.com includes these links is used as the URL for an image? Even though nothing a script from advertiser.com, this script is considered to have has been clicked, that action will still be performed on behalf of the origin http://example.com. This allows the script to the logged-in user because the URL is requested when the browser modify the web page from example.com. It is important to note attempts to get the supposed image. Cross-site request forgery oc- that many scripts, including scripts dealing with embedding adver- curs when the user visits a web page which accesses a URL that tisements, require this ability. The script cannot subsequently read performs an action (using that user's privileges) on another web or modify content originating from advertiser.com directly; page (even if the user never sees the URL being loaded).
it can only read and modify content from example.com, or con-tent which has inherited that origin.
Cross-site scripting (XSS)
While the sandbox and same origin policy protect the host and While no precise definition of cross-site scripting seems to be prevent many types of network communication, opportunities for universally accepted, the core concept behind cross-site scripting recursive script inclusion, unrestricted outbound communication, (XSS) is that of a security exploit in which an attacker inserts code cross-site request forgery, and cross-site scripting allow consider- onto a page returned by an unsuspecting web server [5, 6]. This able scope for security vulnerabilities. We explore each of these code may be stored or reflected, it may contain JavaScript or just issues below.
HTML, and it may use third party sites as sources or rely onlyupon the resources of the targeted server. With such ambiguity, Recursive script inclusion
it is possible to have a cross-site scripting attack which neither The same origin policy states that scripts can read or modify uses scripting nor is cross-site. Typically, however, XSS attacks any part of a page with a matching origin. This includes allow- 1While this attack can now be mitigated by httpOnly [23], other ing scripts to add additional script tags to the document. These new information (including form data) can still be stolen this way.
these are all important types of attacks, by focusing on the prob- lem of unapproved communication we can create a simple, practi- cal solution that addresses the security concerns described in Sec- tion 2. Mechanisms to address these other threats largely comple- ment rather than overlap with the protections of SOMA (see Sec- Table 2: JavaScript access to other content with SOMA (per-
The first part of SOMA we discuss is the manifest file, which missions denoted SO are dictated by the long-standing same
contains a list of domains from which the origin domain wishes to allow included content. This idea is similar to the manifestsprovided in Tahoma [7]. This manifest file is always stored in theroot directory and will have the name soma-manifest.
involve JavaScript code engaging in cross-domain communication For example, the manifest file for maps.google.com would with malicious web servers.
be found at http://maps.google.com/soma-manifest Code injection for cross-site scripting usually occurs because and might appear similar to Figure 1. If this file was set, the browser user-supplied data is not sufficiently sanitized before being stored would enforce that only content from those locations could be em- and/or displayed to other users. Although the existence of such vul- bedded in a page coming from maps.google.com. Note that nerabilities is not a flaw in the same origin policy, per se, the same each location definition includes protocol, domain and optionally origin policy does allow the injected code access to content of the port (the default one for the protocol is used if none is specified), originating site. Specifically, it can then steal information associ- so that origins are defined the same way as in the current same ori- ated with that domain or perform actions on behalf of the user.
Some existing proposals to address cross-site scripting and other JavaScript security issues are described in greater detail in Sec- tions 6. Here we note that no current proposal targets the cross- domain communication involved in most JavaScript exploits.
SOMA DESIGN
The Same Origin Mutual Approval (SOMA) policy tightens the same origin policy so that it can better handle exploits as discussedin Section 2, including cross-site scripting and cross-site request Figure 1: Sample manifest for maps.google.com
forgery. SOMA requires that both the origin web site and the siteproviding included content approve of the request before the browser If the origin A has a manifest that contains B, we denote this allows any external content to be fetched for a page. Adding these using AAB. This symbol is a visual way to indicate that A is extra checks gives site operators much more control over what gets the origin (the outer cup) and B is a content provider web site for included into or from their sites. These changes are shown in Table that origin (the inner circle). Similarly, if A's manifest does not 2. While the differences (relative to Table 1) are all in the Fetch include C, we write ACC. If ACC then the browser will not column, a "fetch" can also be used to leak (send out) information allow anything in the pages from A to contact the domain C, thus such as cookies, as discussed earlier.
code, images, iframes, or any other content will not be loaded from A key idea behind SOMA is that security policy should be de- C. Trust is not transitive (i.e. AAB and BAC does not imply cided by site operators, who have a vested interest in doing it cor- rectly and the knowledge necessary to create secure policies, rather By convention, it is not necessary to include the origin domain than end users. Having said that, we cannot expect site operators itself in the manifest file as inclusions from the origin are assumed to create complex policies—their time and resources are limited.
to be allowed.
Thus SOMA works at a level of granularity that is both easy tounderstand and specify, that of DNS domains and URLs.
The approval files provide the other side of the mutual approval Threat Model
by allowing domains to indicate sites which are allowed to include We assume that site administrators have the ability to create and content from them. A SOMA approval file is similar in function control top-level URLs (static files or scripts) and that web browsers to Adobe Flash's crossdomain.xml [1] but differs in that it is will follow the instructions specified at these locations precisely.
not a single static file containing information about all approved In contrast, we do assume that the attacker controls arbitrary web domains. Instead, it is a script that provides a YES/NO response servers and some of the content on legitimate servers (but not their given a domain as input.
policy files or their server software). Our goal is to prevent a web We use a script to prevent easy disclosure of the list of approved browser from communicating with a malicious web server when a domains, since such a list could be used by an attacker (e.g. to legitimate web site is accessed, even if the content on that site or its determine which sites could be used in a XSRF attack or to deter- partners has been compromised.
mine business relationships). Attackers may still generate such a These assumptions mean that we do not address situations where list by constantly querying soma-approval, but if they knew a an attacker compromises a web server to change policy files, com- list of domains to guess, they could just as easily visit those do- promises a web browser to circumvent policy checks, or performs mains and see if they included any content from the target content intruder-in-the-middle attacks to intercept and modify communi- provider. In addition, the smaller size of the approval responses cations. Further, we do not address the problem of users visiting containing simple YES/NO answers may provide a modest perfor- malicious web sites directly, say as part of a phishing attack. While mance increase on the client side relative to the cost of loading it images, text or JavaScript code. The web browser retrieves this $site_policy = array( 'A.com' => 'YES', content and builds the page using it. It is important to note that it is 'C.net' => 'YES'); the web page (running in the web browser) and not the web serverthat indicates the content, as scripts that are executed on the page if (isset($site_policy[$_GET['d']])) { may request additional content.
Figure 2: Simple soma-approval script written in PHP
a complete list of approved sites (especially for highly connectedsites such as ad servers).
To indicate that A.com is allowed to load content from B.org, B.org needs to provide a script in the web server root directory with the filename soma-approval which returns YES when in-voked through http://B.org/soma-approval?d=A.com.
Negative responses are indicated in a similar manner with the textof NO. If a negative response is received, then the browser refuses to load any content from B.org into a page from A.com. If no filewith the name soma-approval exists, then we assume a default permissive behaviour, described in greater detail in Section 3.6.
To reject all approval requests, soma-approval need only be a static file containing the string NO. Similarly, a static Figure 3: Inclusions allowed by the same origin policy
soma-approval with the word YES suffices to approve all re-quests.
The additional constraints added by SOMA are illustrated in Fig- An alternative proposal that avoids the need for a script involves ure 4. Rather than allowing all inclusions as requested by the web allowing soma-approval to be a directory containing files for page, the modified browser checks first to see if both the page's the allowed domains. Unfortunately, in order to handle our default web server and the external content's web server approve of each permissive behaviour, we would now require two requests: one to other. In Figure 4, web server A is the source of the web page to see if the soma-approval directory exists and another to see if the be displayed. A has a manifest that indicates that it approves of domain-specific file exists. Since most of the overhead of SOMA including content from both B and C (AAB and AAC). When lies in the network requests (as shown in Section 5), we believe the the browser is asked to include content from B in the page from A, better choice is to require a script.2 it makes a request to B to determine if BBA (B approves of A A sample soma-approval script, written in PHP, is shown in incorporating its content). In the example, B approves and its con- Figure 2. This script uses an array to store policy information at the tent is included on the page (since (AAB) ∧ (BBA)). Also in top of the file then outputs the policy as requested, defaulting to NO the example, C's content is not included because CDA (C returns if no policy has been defined. In this example, A.com and C.net are NO in response to a request for soma-approval). D's content is the only approved domains.
not included because ACD (D is not listed in A's manifest). C The symbols used for denoting approval are similar to those used returning CDA prevents pages from A accessing content from C for denoting inclusion in the manifest. If B approves of content in any way (including embedding content or performing cross-site from its site being included into a page with origin A we show this request attacks). ACD prevents web pages from A interacting using BBA. Again, since B is the content provider it is connected with D in any way. Users following hyperlinks to other web sites to the small inner circle, and the origin A is connected to the outer are not affected by SOMA.
cup. If B does not approve of another domain C, this is denoted In the example, A's web pages are trying to use content without BDC. If BDC then the browser will refuse to allow the page C's approval,3 or A's web pages may be attempting a cross-site from C to contact B in any way. No scripts, images, iframes or request forgery against C. In either case, the browser does not other content from B will be loaded for the web page at C. Similar allow the communication.
to manifests, trust is not transitive (i.e. ABB and BBC does not In the case of content inclusions from D, the page is trying to in- clude content but the manifest for A does not include D. The con- It is important to note that BBA is not the same as, nor does it tent from D is thus not loaded and not included (the web browser necessarily imply, that AAB. It is possible for one party to allow never checks to see if D would have granted approval or not). In the inclusion and the other to refuse. Content is only loaded if both this fashion SOMA prevents information from being sent to or re- parties agree (i.e. (AAC) ∧ (CBA)).
ceived from an unapproved server.
Process of approval
Figure 3 illustrates inclusions currently allowed within the same The process the browser goes through when fetching content is origin policy. The web page itself indicates the content it needs, be described in Figure 5. First, the web browser gets the page fromserver A. In parallel, the browser retrieves the manifest file from 2 It is possible to simulate the script functionality using files and URL rewriting on the web server, but the configuration required is 3Such inclusions may be considered stealing, either of the content complex due to the need to handle absent files as NO responses.
itself or of the bandwidth needed to load the content.
1. Request page
3. Return page
4. Return manifest
(assume AAC is in
If A wants to includecontent from C Figure 4: Inclusions allowed within the SOMA policy
server A using the same protocol (i.e. if the page is served over 6. Return YES or NO
HTTPS, then the manifest will be retrieved over HTTPS). In this example, the web page requires content from web server C, so the browser first checks to see if C is in A's manifest. If ACC,then the content is not loaded. This must be done first and sepa- 7. Request content
rately to prevent unauthorized outbound communication. If AAC,then the browser verifies C's reciprocal approval by checking thesoma-approval details on C (again using the same protocol 8. Return content
as the pending content request). If CDA then the browser againrefuses to load the content. If CBA then the browser gets anynecessary content from C and inserts it into the web page. In order Figure 5: The mutual approval procedure
to protect against DNS rebinding attacks [15], the browser sendsthe approval request (step 5) and subsequent content request (step7) to the same server IP address.
or to receive stolen information, the list of potential attackers is nar- If the request for soma-approval times out, the browser might rowed significantly, either to insiders at the web site in question, or either retry, or alternately assume a NO response, the latter possibly to one of its approved partners. As we explain below, this change mitigating some denial of service attacks.
provides substantial additional protection in practise.
One key factor making SOMA a feasible defence is that the costs Compatibility with existing sites
of implementation and operation are borne by those parties who In order to avoid breaking current web pages, SOMA defaults stand the most to benefit and who are most suited to bear its costs.
to a permissive mode if the manifest or approval files do not ex- It also helps those who wish more control over what sites embed ist. These defaults reflect current web page behaviour where all their content.
inclusions are allowed.
Recursive Script Inclusion soma-manifest file does not exist on the origin, all inclusions are considered to be permitted by the origin site.
Script inclusion is only allowed from mutually approved do- 2. If the content provider has no soma-approval file, then mains. This rule applies even if a script is included recursively any site is allowed to include content from this provider. In – the origin still needs to allow the inclusion and the script source other words, the default soma-approval is YES if no file must approve of the origin. The use of the manifest to constrain all inclusions means that attackers will no longer be able to store at- Note that these checks are independent, i.e., the lack of a tack code on external domains unless they are mutually approved.
Many current attacks rely on the ability to store code externally soma-approval file and vice-versa.
[27], therefore SOMA will force attackers to use new attack strate-gies. While restricting recursive script inclusion can potentiallybreak promiscuous third-party scripts, we see this promiscuity as being inherently dangerous and worth limiting (see Section 2.1).
Unrestricted outbound communication SOMA constrains JavaScript's ability to communicate by limit- Outbound communication under SOMA is controlled so that (ex- ing it to mutually approved domains. Since many attacks rely upon plicit) information can only flow to and from mutually approved JavaScript's ability to communicate with arbitrary domains, this partners. Thus, attackers who wish to get information from a page curtails many types of exploitive activity in web browsers. Whereas now cannot have the browser send it to any arbitrary web server.
currently any web server can be used to host malicious JavaScript This change blocks many existing cookie-stealing and similar in- formation theft attacks, forcing attackers to compromise an ap- ever, without the cross-site component, the remaining attacks are proved partner in order to get such information.
just single site code injection attacks, not cross-site attacks.
While SOMA provides no protection against local covert com- munications channels, it does protect against most timing attacks based upon cached content [11], simply because with SOMA the SOMA allows content providers more control over who uses attacker's website will in general not be approved by the victim's their content. Thus SOMA offers a new way to prevent "bandwidth for content inclusion.
theft" where someone is including images or other content froma (non-consenting) content provider into their page using a direct Cross-site request forgery link to the original file. Many techniques require the web server to Cross-site request forgery attacks occur when a malicious web verify the HTTP Referer header, which can be problematic (as site causes a URL to be loaded from another, victim web site.
discussed in Section 4.1.3). SOMA provides a technique to do the SOMA dictates that URLs can only be loaded if a site has been verification in the browser, not relying on HTTP Referer.
mutually approved, which means that a site is only vulnerable to Also known as hotlinking or inline linking, bandwidth theft is cross-site request forgery from sites on its approval list. Specifi- used maliciously by phishing sites, but may also be used uninten- cally, the approval files limit the possible attack vectors for a cross- tionally by people who do not know better [4]. Regardless of the site request forgery attack, while the manifest file ensures that an intent, this can still be damaging. While the content provider is origin site cannot be used in an attack on another arbitrary site.
paying hosting costs associated with serving up that file, it may be SOMA thus allows a new approach to protect web applications pulled in by, for example, a very popular blog or aggregate site that from cross-site request forgery. Any page which performs an ac- would generate a huge number of additional views. At the extreme, tion when loaded could be placed on a subdomain (by the server this could result in the content provider exceeding their bandwidth operator) which grants approval only to trusted domains, such as cap and being charged extra hosting fees or having their site shut those they control. This change would limit attacks to cases where down. SOMA helps prevent this sort of denial of service attack.
the user has been fooled into clicking on a link. It is unlikely that Browsers (with SOMA enabled) would enforce access rules set by sites will need to grant external access to action-causing scripts: even voting sites, which generally want to make it easy for peopleto vote from an external domain with just a click, usually use an intermediate page to prevent vote fraud.
SOMA is designed to gracefully handle sites which are unaware SOMA also leaks less information to sites than the current of SOMA or have not yet been configured. More specifically, if Referer HTML header (which is also sometimes used to pre- the soma-manifest and/or soma-approval files do not exist vent cross-site request forgery [24]). Because the Referer header (or do not contain SOMA specific identifying strings), the browser contains the complete URL (and not just the domain), sensitive in- defaults to current permissive behaviour, that is, it assumes that formation can currently be leaked [20]. Many have already realized inclusions are allowed. Thus, a SOMA-enabled browser can run the privacy concerns related to the Referer URL and have im- on current web pages without any difference in behaviour.
plemented measures to block or change this header [41, 34]. These If only the origin site has a soma-manifest, then SOMA still proposals also prevent current cross-site request forgery detection provides partial security coverage, enforcing the policy that is de- attempts; however, they do not conflict with SOMA.
fined in the soma-manifest. If the origin site does not have amanifest file, but the content provider gives approval information through soma-approval then the policy defined by the content SOMA blocks the "cross" part of cross-site scripting, since in- provider is enforced by the SOMA-enabled browser.
formation can no longer be loaded from or sent to external, unap- In order to verify that files returned in response to requests for proved domains. This change forces attackers to either compromise soma-manifest and soma-approval are related to SOMA, the targeted origin host or one of its mutually approved partners, or we stipulate that the first line of the soma-manifest file must to inject their entire attack code into the web page. 4 contain SOMA Manifest and the soma-approval file must Even if attack code manages to load, its communication chan- contain only the word YES or NO. This is necessary since many nels are limited. Many attacks require that information such as websites return a generic page even when the request has not been credit card numbers be sent to the attacker for later use; this will found, and this must not be confused with intentional responses to no longer be possible with SOMA. Other attacks require the user SOMA requests.
to load dangerous content hosted externally, and these would also The full benefits of SOMA are available when origins and con- tent providers both provide SOMA-related files, but the design is Thus, while some forms of cross-site scripting attacks remain such that it is possible for either side to start providing files with- viable, they are limited to attacks on the existing page that do not out needing extensive coordination to ensure that both are provided require communication through the browser to other non-approved at the same time. In other words, incremental deployment is pos- domains. For example, it is not possible to steal cookies if there is sible. In addition, even if one site refuses to provide policy files no way to send the cookie information out to the attacker. It is pos- for whatever reason, others can still obtain lesser security benefits.
sible that the site itself could provide the way (for example, cookies Moreover, the support of SOMA at servers need not be synchro- could be emailed out of a compromised webmail client or posted nized with deployment of SOMA at browsers.
on a blog). Or, the attacker could instead choose to deface the page, A more security-oriented default policy would be possible, with since this attack requires the script only to modify the page. How- SOMA assuming a NO response if the manifest or approval files arenot found by the browser. This could potentially provide additional 4 Note that since the code needed to mount many attacks is of signif- security even on sites which do not provide policy, as well as en- icant size (e.g., setting appropriate style attributes as camouflage),when combined with SOMA, simple length restrictions already in couraging sites which do not have policies to set them. However, it place on some user content may be sufficient to prevent many at- would break almost all existing web pages, almost surely prevent- ing the adoption of SOMA. The permissive default was chosen to reflect current browser behaviour and to make it easier for SOMA the necessary inclusions will be known in advance and necessary to be deployed.
policy could be created by a system administrator or web developer.
For an evaluation of the performance impact of SOMA, see Sec- The browser, the origin sites, and content inclusion provider sites all bear the costs in deploying SOMA. Note that unlike some so- lutions which rely heavily upon user knowledge (e.g., the NoScript SOMA is designed to improve the same origin policy by impos- add-on for Mozilla Firefox [22]), SOMA requires no additional ef- ing further constraints upon external inclusions and thus external fort on the part of the user browsing the web site. Instead, policies communications. It does not prevent attacks that do not require ex- are set by server operators, who are expected have more informa- ternal communications such as code and content injection. SOMA tion about what constitutes good policy for their sites.
can restrict outside communication frequently seen in current at-tack code [27].
Deployment in the browser SOMA does not stop attacks to or from mutually approved part- The SOMA policy is enforced by the web browser, so changes ners. In order to avoid these attacks, it would be necessary to im- are required in the browser. We have created a prototype add-on for pose finer-grained control or additional separation between com- Mozilla Firefox 2 and 3 as discussed in greater detail in Section 5.
ponents. This sort of protection can be provided by the mashupsolutions described in Section 6, albeit at the cost of extensive and Deployment on origin sites often complex web site modifications.
Each origin site which wishes to benefit from the protections of SOMA cannot stop attacks on the origin where the entire at- SOMA needs to provide a soma-manifest file. This is a text file tack code is injected, if no outside communication is needed for containing a list of content-providing sites from which the origin the attack. This could be web page defacement, same-site request wishes to include content. As mentioned earlier, content providers forgery, or sandbox-breaking attacks intended for the user's ma- are specified by domain name, protocol and (optionally) port.
chine. Some complex attacks might be stopped by size restrictions This list can be determined by looking at pages on the site and on uploaded content. More subtle attacks might need to be caught compiling a list of content providers. This could be automated us- by heuristics used to detect cross-site scripting. Some of these so- ing a web crawler, or done by an admin who is willing to set pol- lutions are described in Section 6.
icy. (It is possible that sites will wish to set more restrictive policy SOMA cannot stop attacks from malicious servers not includ- than the site's current behaviour.) We examined the main page on ing content from remote domains. These would include phishing popular sites to determine the approximate complexity of manifests attacks where the legitimate server is not involved.
required. These results are detailed in Section 5.5.2.
Deployment on content provider sites Content providers wishing to take advantage of SOMA need to provide either a file or script which can handle requests tosoma-approval. The time needed to create this policy script In order to test SOMA, we created an add-on for Mozilla Firefox depends heavily upon the needs of the site in question, and may 2.0, licensed under the GNU GPL version 2 or later.5 It can be range from a simple yes-to-all or no-to-all to more complex poli- installed in an unmodified installation of Mozilla Firefox the same cies based upon client relationships. Fortunately, simple policies way as any other add-on: the user clicks an installation link and is are likely to be desired by smaller sites (which are unlikely to have prompted to confirm the install. If they click the install button, the the resources to create complex policies), and complex policies are add-on is installed and begins to function after a browser restart.
likely to be required only by sites who have more expertise.
The SOMA add-on provides a component that does the neces- Many sites will not wish to be external content providers and sary verification of the soma-manifest and soma-approval their needs will be easily served by a soma-approval file that files before content is loaded.
just contains NO. Such a configuration will be common on smaller Since it was not possible to insert test policy files onto sites over sites such as personal blogs. It will also be common on high- which we had no control, we used a proxy server to simulate the security sites such as banks, who want to be especially careful to presence of manifest and approval files on popular sites.
avoid XSRF and having their images used by phishing sites. Phish-ing sites will have to copy over images as opposed to linking to the original image.
The primary overhead in running SOMA is due to the additional Other sites may wish to be content providers to everyone. Sites latency introduced by having to request a soma-manifest or such as Flickr and YouTube that wish to allow all users to include soma-approval from each domain referenced on a web page.
content will probably want to have a simple YES policy. This is While these responses can be cached (like other web requests), the achieved by creating a soma-approval file that contains the initial load time for a page is increased by the time required to com- word YES, or not hosting a soma-approval file (as the default plete these requests. Because the manifest can be loaded in parallel with the origin page, we do not believe manifest load times will af- The sites requiring the most configuration are those who want to fect total page load times. Because soma-approval files must allow some content inclusions rather than all or none. For example, be retrieved before contacting other servers, however, overhead in advertisers might want to provide code to sites displaying their ads.
requesting them will increase page load times.
The domains that need to be approved can be determined using the Because sites do not currently implement SOMA, we estimate list of domains already associated with each clients profile. This SOMA's overhead using observed web request times. First, we de- database could then be queried to generate the approval list. Or a termined the average HTTP request round-trip time for each of 40 company with several web applications might want to keep them onseparate domains but still allow interaction between them. Again, representative web sites6 on a per-domain basis using PageStats [9].
Origin sites: Manifest files We used this per-domain average as a proxy for the time to retrieve To determine approximate sizes for manifests, we used the PageS- a soma-approval from a given domain. Then, to calculate page tats add-on [9] to load the home page for the global top 500 sites as load times using SOMA, we increase the time to request all content reported by Alexa [2] and examined the resulting log, which con- from each accessed domain by the soma-approval request es- tains information about each request that was made. On average, timate for that domain. The time of the last response from any each site requested content from 5.45 domains other than the one domain then serves as our final page load time.
being loaded, with a standard deviation of 5.3. The maximum num- After running our test 30 times on 40 different web pages, we ber of content providers was 32 and the minimum was 0 (for sites found that the average additional network latency overhead due that only load from their own domain).
to SOMA increased page load time from 2.9 to 3.3 seconds (or Of course, a site's home page may not be representative of its 13.28%) on non-cached page loads. On cached page loads, our entire contents. So, as a further test we traversed large sections of overhead is negligible (since soma-approval is cached). We a major news site (www.cbc.ca) and determined that the number note that this increase in latency is due to network latency and not of domains needed in the manifest was approximately 45; this value CPU usage. If we assume that 58% of page loads are revisits [37], was close to the 33 needed for that particular site's home page.
the average network latency overhead of SOMA drops to 5.58%.
Given the remarkable diversity of the Internet, there probably Because soma-approval responses are extremely small (see exist sites today that would require extremely large manifest files.
Section 5.5.3), they should be faster to retrieve than the average This cursory survey, however, gives evidence that manifests for round-trip time estimate used in our experiments. Thus, these val- common sites would be relatively small.
ues should be seen as a worst-case scenario; in practice, we expectSOMA's overhead to be significantly less.
Content provider sites: Approval files Compatibility with Existing Web pages
Approvals result in tiny amounts of data being transferred: either a YES or NO response (around 4 bytes of data) plus any necessary To test compatibility with existing web pages, the global top 45 sites as ranked by Alexa [2] were visited in the browser with Using data from the top 500 Alexa sites [2], we examined 3244 and without the SOMA add-on. No SOMA compatibility issues cases in which a content provider served data to an origin site.
were detected. In addition, one author ran the SOMA add-on for The average request size was 10459 bytes. Because many content 2 weeks while doing regular browsing, and no SOMA incompati- providers are serving up large video, however, the standard devia- bilities were observed. These results were expected, as SOMA was tion was fairly large: 118197 bytes. The median of 2528 bytes is designed for compatibility and incremental deployment.
much lower than the average. However, even this smaller mediandwarfs the 4 bytes required for a soma-approval response. As such, we feel it safe to say that the additional network load on con- In order to verify that SOMA actively blocks information leak- tent providers due to SOMA is negligible compared to the data they age, cross-site request forgery, cross-site scripting, and content steal- are already providing to a given origin site.
ing, we created examples of these attacks. We specifically testedthe following attacks with the SOMA add-on: 1. A GET request for an image on another web site (testing both RELATED WORK
GET based XSRF as well as content stealing).
Web-based execution environments have all been built with the 2. A POST request to a page on another web site done through understanding that unfettered remote code execution is extremely JavaScript (testing POST based XSRF).
dangerous. SSL and TLS can protect communication privacy, in- 3. An iframe inclusion from another web site (testing iframe tegrity, and authenticity, while code signing [30, 35] can prevent the injection based XSS).
execution of unauthorized code; neither, however, protect against 4. Sending either a cookie or personal information to another the execution of malicious code within the browser. Java [8] was web site (testing information leakage).
the first web execution environment to employ an execution sand- 5. A script inclusion from another web site (testing XSS injec- box [39] and the same origin policy for restricting network commu- nication. Subsequent systems for executing code within a browser, All attacks were hosted at domain A and used domain B as the including JavaScript, have largely followed the model as originally other domain involved. All attacks were successful without SOMA.
embodied in Java applets.
With SOMA we found that these attacks were all prevented by ei- While there has been considerable work on mitigating the fail- ther a manifest at domain A not listing B or a soma-approval ures of language-based sandboxing [18] and on sandboxing other, at domain B which returned NO for domain A.
less trusted code such as browser plugins and helper applications[12], only recently have researchers begun addressing the limita- tions of sandboxing and same origin policy with respect to JavaScriptapplications.
Browser: SOMA Add-on Many researchers have attempted to detect and block malicious The SOMA add-on, when prepared into the standard XPI pack- JavaScript. Some have proposed to instrument JavaScript automat- age format used by Mozilla Firefox, is 16kB. Uncompressed, the ically to detect known vulnerabilities [29], while others have pro- entire add-on is 18kB. The component which does the actual SOMA posed to filter JavaScript to prevent XSS [19] and XSRF [17] at- mutual approval process is 12kB; the rest is installation files and tacks. Another approach has been to perform dynamic taint track- chrome so that the browser provides a visual indication that the ing (combined with static analysis) to detect the information flows add-on is loaded.
associated with XSS attacks [38]. Instead of attempting to de-tect dangerous JavaScript code behaviour before it can compromise 6 Our representative sample included banks, news sites, web e-mail, user data, SOMA prevents unauthorized cross-domain information e-commerce, social networking, and less popular sites.
flows using site-specific policies.
Recently several researchers have focused on the problem of web DISCUSSION AND CONCLUSION
mashups, which may be created on the client or server. Client- Most JavaScript-based attacks require that compromised web side mashups are composite JavaScript-based web pages that draw pages communicate with attacker-controlled web servers. Here we functionality and content from multiple sources. To make these propose an extension to same origin policy—the same origin mu- mashups work within the confines of same origin policy, remote tual approval (SOMA) policy—which restricts cross-domain com- content must either be separated into different iframes or all code munication to a web page's originating server and other servers that must be loaded into the same execution context. The former so- mutually approve of the cross-site communication. By prevent- lution is in general too restrictive while the latter is too permis- ing inappropriate or unauthorized cross-domain communication, sive; client-side mashup solutions are designed to bridge this gap.
attacks such as cross-site scripting and cross-site request forgery Two pioneering works in this space are Subspace [16] and Mashu- can be blocked.
pOS [14, 40]. SOMA restricts communication between the web The SOMA architecture's benefits versus other JavaScript de- page (browser) and servers while mashup solutions restrict local fences include: 1) it is incrementally deployable with incremen- communication between elements on the page.
tal benefit; 2) it imposes no configuration or usage burden on end SOMA breaks client-side mashups which use unapproved code.
users; 3) the required changes in browser functionality and server In order for a mashup to work with SOMA, every web site involved configuration affect those who have the most reason to be con- must explicitly allow participation. While such restrictions may in- cerned about security, namely the administrators of sensitive web hibit the creation of novel, third party mashup applications, they servers and web browser developers; 4) these changes are easy to also prevent attackers from creating malicious mashups (e.g., com- understand, simple to implement technically, and efficient in exe- binations of a legitimate bank's login page and a malicious login cution; and 5) it gives server operators a chance to specify what box). Given the state of security on the modern web, we believe sites can interact with their content. While SOMA does not prevent such a trade-off is beneficial and, moreover, necessary. SOMA does attackers from injecting JavaScript code, with SOMA such code not affect server-side mashups.
cannot leak information to attackers without going through an ap- While the general problem of unauthorized information flow is proved server.
a classic problem in computer security [10], little attention has We believe that SOMA represents a reasonable and practical been paid in the research community to the problems of unautho- compromise between benefits (increased security) and costs (adop- rized cross-domain information flow in web applications beyond tion pain). Perhaps more significantly, our proposal of the SOMA the strictures of same origin policy—this, despite the fact that XSS architecture highlights that the ability to create web pages using ar- and XSRF attacks very heavily rely upon such unauthorized flows.
bitrary remote resources is a key enabling factor in web security Of course, the web was originally designed to make it easy to em- exploits (including some techniques used in phishing). While other bed content from arbitrary sources. With SOMA, we are simply JavaScript defences will no doubt arise, we believe that among the advocating that any such inclusions should be approved by both contributions of this paper are a focus on the underlying problem, namely, deficiencies in the JavaScript same origin policy, and the While SOMA is a novel proposal, we based the design of identification of several important characteristics of a viable solu- soma-approval and soma-manifest on existing systems.
It is easy to dismiss any proposal requiring changes to web in- crossdomain.xml [1] mechanism of Flash. External content frastructure; however, there is precedence for wide scale changes may be included in Flash applications only from servers with a to improve security. Indeed, much as open email relays had to be crossdomain.xml file [1] that lists the Flash applications' orig- restricted to mitigate spam, we believe that arbitrary content inclu- sions must be restricted to mitigate cross-site scripting and cross- soma-approval request can be arbitrarily complex, we have site request forgery attacks. We hope this insight helps clarify the chosen to specify that it be a server-side script rather than an XML threats that must be considered when creating next-generation web file that must be parsed by a web browser.
technologies and other Internet-based distributed applications.
The soma-manifest file was inspired by Tahoma [7], an ex- Acknowledgements. The first and second authors acknowledge
perimental VM-based system for securing web applications. Tahoma NSERC for funding their PGS D scholarships. The third author allows users to download virtual machine images from arbitrary acknowledges NSERC for an NSERC Discovery Grant and his servers. To prevent these virtual machines from contacting unau- Canada Research Chair in Network and Software Security. The thorized servers (e.g., when a virtual machine has been compro- fourth author acknowledges an NSERC Discovery Grant. We also mised), Tahoma requires every VM image to include a manifest thank RIM and NSERC ISSNet for partial funding, as well as anony- specifying what remote sites that VM may communicate with.
mous referees for their comments.
Note that by themselves Flash's crossdomain.xml and Tahoma's server manifest do not provide the type of protection pro- vided by SOMA. With Flash, a malicious content provider can al- [1] Adobe Systems Incorporated. External data not accessible ways specify a crossdomain.xml file that would allow a com- outside a Macromedia Flash movie's domain. Technical promised Flash program to send sensitive information to the at- Report tn_14213, Adobe Systems Incorporated, Feb 2006.
tacker. With Tahoma, a malicious origin server can specify a man- [2] Alexa top 500 sites. Web page (viewed 14 Apr 2008).
ifest that would cause a user's browser to send data to an arbitrary web site, thus causing a denial-of-service attack or worse. By in- cluding both mechanisms, we address the limitations of each.
[3] R. Auger. The cross-site request forgery (CSRF/XSRF) FAQ.
Subsequent to our preliminary report [25], B. Sterne of Mozilla Web page, Jan 2007. http://www.cgisecurity.
introduced a related proposal called Site Security Policy (SSP) [36] which is still in development. Another related proposal by Schuh [4] R. Berends. Bandwidth stealing. Web page, Apr 2001.
[33] involves the browser enforcing firewall-style rulesets provided by the origin.
[5] CERT advisory CA-2000-02 malicious HTML tags [24] A. D. Miglio. "Referer" field used in the battle against online embedded in client web requests. Web page, Feb 2000.
fraud. Web page, Jan 2008.
[6] The cross site scripting (XSS) FAQ. Web page, Aug 2003.
[25] T. Oda, G. Wurster, P. van Oorschot, and A. Somayaji.
SOMA: Mutual approval for included content in web pages.
[7] R. S. Cox, J. G. Hansen, S. D. Gribble, and H. M. Levy. A Technical Report TR-08-07, School of Computer Science, safety-oriented platform for web applications. In Proc. IEEE Carleton University, Apr 2008.
Symposium on Security and Privacy, pages 350–364, 2006.
[26] N. Provos, P. Mavrommatis, M. A. Rajab, and F. Monrose.
[8] D. Dean, E. Felten, and D. Wallach. Java security: From All your iframes point to us. In Proc. 17th USENIX Security HotJava to Netscape and beyond. In Proc. IEEE Symposium Symposium, Aug 2008.
on Security and Privacy, pages 190–200, 1996.
[27] N. Provos, D. McNamee, P. Mavrommatis, K. Wang, and [9] S. DeDeo. Pagestats extension. Web page, May 2006.
N. Modadugu. The ghost in the browser: Analysis of web-based malware. In Proc. HotBots '07, 2007.
[10] D. E. Denning. A lattice model of secure information flow.
[28] J. Reimer. Microsoft apologizes for serving malware. Ars Communications of the ACM, 19(2):236–243, 1976.
Technica, Feb 2007.
[11] E. W. Felten and M. A. Schneider. Timing attacks on web [29] C. Reis, J. Dunagan, H. J. Wang, O. Dubrovsky, and privacy. In Proc. 7th ACM CCS, pages 25–32, 2000.
S. Esmeir. BrowserShield: Vulnerability-driven filtering of [12] I. Goldberg, D. Wagner, R. Thomas, and E. Brewer. A secure dynamic HTML. In Proc. IEEE Symposium on Security and environment for untrusted helper applications (confining the Privacy, May 2006.
wily hacker). In Proc. 6th USENIX Security Symposium, [30] A. Rubin and D. Geer. Mobile code security. IEEE Journal on Internet Computing, 2(6):30–34, 1998.
[13] J. Grossman and T. Niedzialkowski. Hacking intranet [31] J. Ruderman. The same origin policy. Web page, Aug 2001.
websites from the outside – JavaScript malware just got a lot more dangerous. In Blackhat USA, Aug 2006.
[14] J. Howell, C. Jackson, H. Wang, and X. Fan. MashupOS: [32] B. Schiffman. Rogue anti-virus slimeballs hide malware in Operating system abstractions for client mashups. In Proc. ads. Wired, Nov 2007.
Workshop on Hot Topics in Operating Systems, May 2007.
[33] J. Schuh. Same-origin policy part 2: Server-provided [15] C. Jackson, A. Barth, A. Bortz, W. Shao, and D. Boneh.
policies? Web page, Feb 2007.
Protecting browsers from DNS rebinding attacks. In Proc. 14th ACM CCS, 2007.
[16] C. Jackson and H. J. Wang. Subspace: secure cross-domain [34] T. Scott. Smarter image hotlinking prevention. A List Apart, communication for web mashups. In Proc. 16th International World Wide Web Conference, pages 611–620, 2007.
[35] R. Sekar, C. R. Ramakrishnan, I. V. Ramakrishnan, and S. A.
[17] N. Jovanovic, E. Kirda, and C. Kruegel. Preventing cross site Smolka. Model-carrying code (MCC): a new paradigm for request forgery attacks. In Proc. 2nd IEEE Conference on mobile-code security. In Proc. 2001 NSPW, pages 23–30, Security and Privacy in Communication Networks (SecureComm), Aug 2006.
[36] B. Sterne. Site security policy draft (version 0.2). Web Page, [18] K. Keahey, K. Doering, and I. Foster. From sandbox to playground: Dynamic virtual environments in the grid. In Proc. 5th IEEE/ACM International Workshop on Grid Computing, pages 34–42, 2004.
[37] L. Tauscher and S. Greenberg. How people revisit web [19] E. Kirda, C. Kruegel, G. Vigna, and N. Jovanovic. Noxes: A pages: empirical findings and implications for the design of client-side solution for mitigating cross site scripting attacks.
history systems. In International Journal of Human In Proc. 21st ACM Symposium on Applied Computing, Apr Computer Studies, 1997.
[38] P. Vogt, F. Nentwich, N. Jovanovic, C. Kruegel, E. Kirda, [20] J. Kyrnin. Are you invading your customers' privacy? Web and G. Vigna. Cross site scripting prevention with dynamic page (viewed 14 Apr 2008). http://webdesign.
data tainting and static analysis. In Proc. 14th NDSS Symposium, Feb 2007.
[21] V. T. Lam, S. Antonatos, P. Akritidis, and K. G.
[39] R. Wahbe, S. Lucco, T. E. Anderson, and S. L. Graham.
Anagnostakis. Puppetnets: misusing web browsers as a Efficient software-based fault isolation. SIGOPS Operating distributed attack infrastructure. In Proc. 13th ACM CCS, System Review, 27(5):203–216, 1993.
pages 221–234, 2006.
[40] H. J. Wang, X. Fan, C. Jackson, and J. Howell. Protection [22] G. Maone. NoScript - JavaScript/Java/Flash blocker for a and communication abstractions for web browsers in safer Firefox experience! Web page (viewed 14 Apr 2008).
MashupOS. In 21st ACM SOSP, Oct 2007.
[41] WordPress.org. Enable sending referrers. Web page (viewed [23] Microsoft. Mitigating cross-site scripting with HTTP-only 14 Apr 2008). http://codex.wordpress.org/ cookies. Web page (viewed 18 Jul 2008).

Source: https://www.ccsl.carleton.ca/paper-archive/oda-ccs-08.pdf