SOMA: Mutual Approval for Included Content in Web Pages Terri Oda, Glenn Wurster, P.C. van Oorschot, Anil Somayaji Carleton Computer Security Lab Carleton University, Canada In Proc. 15th ACM CCS, 2008 Presenter: Fu-Chi, Ao

2009/05/192 Outline Introduction Background and Motivation SOMA Design Design Evaluation Prototype Related Work Conclusion and Comments

2009/05/193 Introduction Unrestricted information flows are a key security weakness of current web design Proposes a policy for improving the same origin policy by imposing further constraints upon external inclusions and thus external communications in web pages, called Same Origin Mutual Approval (SOMA) Requires the browser to check that both site operator of the page and the third party content provider approve of the inclusion before any communication is allowed (including adding anything to the page) Implemented as an add-on for Mozilla Firefox 2 and 3

2009/05/194 Background and Motivation While the sandbox and same origin policy protect the host and prevent many types of network communication, opportunities allow for considerable scope for security vulnerabilities. Requires that information be sent or retrieved from arbitrary, often malicious, web servers –Cross-site scripting, cross-site request forgery, and other attacks

2009/05/195 SOMA Design Security policy should be decided by site operators, who have a vested interest in doing it correctly and the knowledge necessary to create secure policies, rather than end users. –Browsers have to make minimal code changes and web sites must create small, simple policy files Same Origin policy restricts read and modify access Fetching of content is unrestricted

2009/05/196 Threat Model Assume: attacker controls arbitrary web servers and some of the content on legitimate servers (but not their policy files or their server software) Do not address: –Attacker compromises a web server to change policy files –Compromises a web browser to circumvent policy checks –Performs intruder-in-the-middle attacks to intercept and modify communications –User visiting malicious web site directly, say as phishing attack

2009/05/197 Manifest Files A text file containing a list of domains from which the origin domain wishes to allow included content. Always stored in the root directory and will have the name soma-manifest –The manifest file for maps.google.com would be found at Each location definition includes protocol, domain and optionally port : A is the origin (the outer cup) and B is a content provider web site for that origin (the inner circle) :The browser will not allow anything in the pages from A to contact the domain C, thus code, images, iframes, or any other content will not be loaded from C Trust is not transitive

2009/05/198 Approval Files Provide the other side of the mutual approval by allowing domains to indicate sites which are allowed to include content from them. it is a script that provides a YES/NO response given a domain as input. –Prevent easy disclosure of the list of approved domains Could be used in a XSRF attack or to determine business relationships –Provide a modest performance increase on the client side Simple soma-approval script written in PHP  Uses an array to store policy information  Defaults to NO if no policy has been defined

2009/05/199 Approval Files : B.org provides a script in the web server root directory with the filename soma-approval which returns NO when invoked through –The browser will refuse to allow the page from C to contact B in anyway No scripts, images, iframes or other content from B.org will be loaded for the web page at C.comB.orgC.com Trust is not transitive Content is only loaded if both parties agree –i.e.

2009/05/1910 Process of Approval Inclusions allowed with SOMA The mutual approval procedure

2009/05/1911 Compatibility with Existing Sites Defaults to a permissive mode if the manifest or approval files do not exist. –Reflect current web page behavior where all inclusions are allowed If the soma-manifest file does not exist on the origin, all inclusions are considered to be permitted by the origin site If the content provider has no soma-approval file, then any site is allowed to include content from this provider These checks are independent

2009/05/1912 Design Evaluation Incremental Deployment –The full benefits are available when origins and content providers both provide SOMA-related files –But it is possible for either side to start providing files without needing extensive coordination to ensure that both are provided at the same time Security Benefits –Recursive Script Inclusion –Unrestricted Outbound Communication –Cross-site Request Forgery (XSRF/CSRF) –Cross-Site Scripting (XSS) –Bandwidth Stealing

2009/05/1913 Recursive Script Inclusion A page creator could choose to include content only from sources they deem trustworthy –Does not mean that all content included will be directly from those sources Any script loaded from a “trustworthy” domain can subsequently load content from any domain. Trust is not transitive –Intentionally malicious script loads additional, dangerous code –“Trustworthy” domain inadvertently loading malicious content

2009/05/1914 Security Benefits - Recursive Script Inclusion Script inclusion is only allowed from mutually approved domains –This rule applies even if a script is included recursively Use Manifest to constrain all inclusions –Attackers will no longer be able to store attack code on external domains unless they are mutually approved

2009/05/1915 Unrestricted Outbound Communication The SOP does not stop any content from other domains from being requested and loaded into the origin page. These requests for content can be abused to send information out to any arbitrary domain. –user’s session, credit card information, personal s, or username and password pairs.

2009/05/1916 Security Benefits - Unrestricted Outbound Communication Any script can read content from the document origin Transmission blocked by SOMA Manifest Blocks cookie-stealing, similar information theft attacks, and timing attacks based upon cached content –Web caching, DNS caching, cached cookies E. W. Felten and M. A. Schneider. Timing attacks on web privacy. In Proc. 7th ACM CCS, pages 25–32, 2000

2009/05/1917 Cross-site Request Forgery (XSRF/CSRF) Tricks the victim into loading a page that contains a malicious request, which inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf –Change the victim's address, home address, or password, or purchase something For most sites, browsers will automatically include with such requests any credentials associated with the site –User’s session cookie, authentication credential, IP address –If the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

2009/05/1918 Security Benefits - Cross-site Request Forgery (XSRF/CSRF) A script can make requests to any domain Request blocked by SOMA Approval –Approval limit the possible attack vectors for a CSRF –Manifest ensures that an origin site cannot be used in an attack on another arbitrary site Leaks less information to site than the current Referrer HTML header –J. Kyrnin. Are you invading your customers’ privacy?

2009/05/1919 Cross-Site Scripting (XSS) An attacker inserts code onto a page returned by an unsuspecting web server –No precise definition seems to be universally accepted Typically involves JavaScript code engaging in cross- domain communication with malicious web servers User-supplied data is not sufficiently sanitized before being stored and/or displayed to other users –Steal information associated with that domain or perform actions on behalf of the user The authors note that no current proposal targets the cross-domain communication involved in most JavaScript exploits

2009/05/1920 Security Benefits - Cross-Site Scripting (XSS) Any script can include other scripts (from any site) Inclusion blocked by SOMA Manifest –Blocks the “cross” part of cross-site scripting, since information can no longer be loaded from or sent to external, unapproved domains

2009/05/1921 Security Benefits - Bandwidth Stealing A document can include content from anywhere –Someone is including images or other content from a (non-consenting) content provider into their page using a direct link to the original file –Exceeding bandwidth cap and being charged extra hosting fees or having site shut down Inclusion blocked by SOMA Approval

2009/05/1922 Deployment Costs (1/2) In the Browser –A prototype add-on for Mozilla Firefox 2 and 3. –Standard XPI package: 16kB –Icon in statusbar indicates that SOMA is running On Origin Sites –Needs to provide a soma-manifest file –Could be automated using a web crawler, or done by an admin who is willing to set policy –Manifests for common sites would be relatively small Used the PageStats to load the home page for the global top 500 sites as reported by Alexa –Avg: 5.45 domains (5.3 stdev); maximum: 32 Traversed large sections of a major news site ( –Domains# needed in the manifest: approximately 45

2009/05/1923 Deployment Costs (2/2) On Content Provider –Need to provide either a file or script which can handle requests to soma-approval –The time needed to create this policy script depends heavily upon the needs of the site in question –Data being transferred YES/NO response (around 4 bytes of data) plus any necessary headers –The additional network load on content providers due to SOMA is negligible Using data from the top 500 Alexa Avg request size: bytes ( bytes stdev); median: 2528 bytes –Estimate probably overstated

2009/05/1924 Prototype - Performance Primary overhead in running SOMA –request a soma-manifest or soma-approval from each domain referenced on a web page The manifest can be loaded in parallel –Not affect total page load times Time to retrieve a soma-approval from a given domain –Avg HTTP request round-trip time for each of 40 representative web sites on a per-domain basis (use PageStats) Page load times: Increase the time to request all content from each accessed domain by the soma-approval request estimate for that domain. The time of the last response from any domain then serves as our final page load time. The avg additional network latency overhead –Non-cached: Increased page load time from 2.9 to 3.3 sec (or 13.28%) –Can drop to 5.58% (58% of revisited page loads)

2009/05/1925 Related Work SOMA breaks client-side mashups which use unapproved code. –In order for a mashup to work with SOMA, every web site involved must explicitly allow participation. Compared to Subspace and MashupOS –SOMA restricts communication between the web page (browser) and servers Focuses on interactions with external servers –Mashup solutions restrict local communication between elements on the page Focuses on interactions within the page

2009/05/1926 Related Work: Mozilla's Content Security Policy First version (“Site Security Policy”) similar to SOMA Most recent version has only manifest –Does not protect against cross site request forgery Other major differences: –policy is per-resource –more complex syntax required

2009/05/1927 Conclusion and Comments Incrementally deployable (with incremental benefit) No configuration/usage burden on end users Required changes/configuration are done by site operators Changes are relatively simple to understand and easy to implement Gives server operators the ability to specify which sites can interact with their content Good idea, but still has limitations (does not stop attacks to or from mutually approved partners, etc.)