COVER FEATURE Security Vulnerabilities in the Same-Origin Policy: Implications and Alternatives

Hossein Saiedian, University of Kansas Dan S. Broyles, Sprint Nextel

The same-origin policy, a fundamental se- However, by using the script in various subdomains, the SOP permits overly restricts Web application develop- data sharing between the pages of example.com and dev. ment while creating an ever-growing list of example.com. Doing so can cause problems, however; the script would let pages from a subdomain such as user- security holes, reinforcing the argument pages.example.com access and alter pages from another that the SOP is not an appropriate security subdomain, such as payments.example.com. model. The SOP incorrectly assumes that all directory paths within the URL belong to the same source. For example, URLs www.example.com/~john and www.example. ne of the first security measures that Internet com/~mary have the same origin, even though they belong browsers incorporated was the same-origin to different users and therefore should not trust each other. policy. As early as Netscape Navigator 2.0, SOP Another problem with the SOP is that it prevents developers O prohibited data sharing between origins—any from delivering dynamic multisource data. As the Internet unique host (such as a website), port, or application pro- and Web technology have progressed, the SOP has not tocol. So, for example, SOP prevents one site’s documents evolved to keep up with the security needs of a more com- from accessing the document contents or properties from plex system, allowing malicious users to circumvent and other sites. Thus, the SOP makes it possible for users to exploit it. visit untrusted websites without allowing them to manipu- In principle, the SOP restriction is a good security late data and sessions on trusted sites. measure because it aims to protect data integrity and confi- If you browse http://example.com/index.htm, the SOP in dentiality. However, it has not kept up with changes in Web the browser would accept or reject script and data accesses technology. The first Web browsers were not designed with from the following sources: security in mind, so developers added the SOP mechanism later to meet some basic security needs. •• http://example.com/about.htm (port 80): accept With the advent of JavaScript, , Web services, and •• https://example.com/doc.html (port 443): reject mashups, clever programmers and hackers have found •• http://google.com/search.php (port 80): reject creative ways to subvert the SOP. Any SOP exploitation can •• http://dev.example.com/more.htm (port 80): reject expose a Web application to attack from malicious code, even if that exploitation comes from a well-intentioned By default, the SOP does not allow subdomains such developer. In addition, those who correct security flaws as dev.example.com to interact with the primary domain. must account for the Web’s unique environment, such as

0018-9162/11/$26.00 © 2011 IEEE Published by the IEEE Computer Society SEPTEMBER 2011 29 COVER FEATURE

statelessness and code mobility.1 To further complicate formance. However, the SOP makes it difficult for Web matters, SOP rules and implementations differ between applications from one source to obtain and display data resources, DOM objects, , cookies, from another. Developers use two common and powerful Flash, Java, JavaScript, ActiveX, Silverlight, plug-ins, and techniques to circumvent the SOP and obtain data from browsers. other domains; the first uses an Ajax proxy, and the second Inexperienced Web programmers who do not know that uses JavaScript object notation with padding (JSONP) script certain objects and actions—such as form submissions tag injection. and tags like Today, banks employ various measures to thwart such attacks, but other sites do not, especially those of small- The remote server will return the requested data so that and medium-size companies whose Web developers do not it calls the callback function, showCurrent: see the need for security measures covering SOP exploits. s h o w C u r r e n t({ Using the Referrer header could be effective against CSRF, but Web applications frequently block this header because “ticker”:”msft”, of privacy concerns, so an application that enforces it “c u r r e n t ”:”2 4.5”, will exclude many users. Applications also strip Referrer “lastclose”:”24.0”, headers from all HTTPS requests. Still worse, hackers can modify the Referrer header, making it unreliable.3 “pctchange”:”2.1”, “30dayavg”:”23.45” The SOP is not the correct security }); mechanism and requires redesign to The webpage will execute the returned JavaScript as meet the access-control requirements if it were native to the page. However, if a hacker were to of Web-based assets. alter the getyourstocks.com site so that it returns malicious JavaScript instead of stock quote data, the browser running this Web app will execute the malicious code. By circum- Adam Barth and his colleagues recommended augmenting venting SOP, the developer has introduced a security hole. browser policy to use an Origin header as opposed to the So how do developers obtain data for a Web application Referrer header to provide CSRF and click-jacking protec- and still maintain security? They need a better security tion.4 The Mozilla security model currently proposes this policy. Basic security logic suggests that third-party entities fix (https://wiki.mozilla.org/Security/Origin). should not have the same access rights as trusted enti- ties, so a policy that lets application developers determine Cross-site scripting access rights for each object might solve many SOP issues. There are two basic ways attackers implement XSS. The first method, considered nonpersistent, introduces mali- HACKER EXPLOITS cious scripts in GET or POST requests that show up in pages Hackers use various exploits to take advantage of SOP returned by the server. For example, an attacker sends an deficiencies. There are many variations of these attacks, e-mail containing a specially crafted hyperlink to a trusted and hackers create new exploits all the time. Here, the website; the URL string includes malicious instructions purpose is not to enumerate every SOP vulnerability and reflected in the page returned by the webserver. The attack attack, but to outline the fundamental flaws in the SOP so takes place when the user clicks on the hyperlink. that readers can better analyze the proposed solutions. The second attack, considered persistent, occurs when the attacker injects malicious scripts into GET or POST Cross-site request forgery actions that the server stores and then dynamically pres- Security experts identified the earliest CSRF as a con- ents to the victim. For example, a malicious user logs into a fused deputy attack. In this type of attack, hackers lure a forum and adds comments containing malicious JavaScript victim to a malicious website to submit a form that points to a discussion thread as follows.5 to a trusted target site in which the victim might have an active session. The trusted webserver receives and pro- Paul’s Blog cesses the form submission request, which looks identical to a legitimate request from the trusted website.

Scavenger Hunt!

CSRF includes any malicious webpage with scripts that make unauthorized requests to trusted sites, hoping to
take advantage of users who have an active session with

Paul: I will award the student the trusted site. For example, a user visits her bank’s web- bringing me the following items:

SEPTEMBER 2011 31 COVER FEATURE

    Flash and other embedded programmable objects that have
  • Yellow #2 pencil
    • access to user-manipulated DOM objects and environment variables. In DOMXSS attacks, the client-side code embeds
  • Secretary’s middle name
    • the malicious code into the webpage; in traditional XSS at-
  • Number of ceiling tiles in our lab tacks, the server embeds the malicious code.
Dynamic pharming Dynamic pharming employs Domain Name System
(DNS) hijacking to deliver a Web document with mali-

Comments

cious JavaScript code, and then in a separate