Securityboundary is a term often used by security professionals. The idea of boundaries is to separate security silos for networks or applications. For example, an application
139
meaningful. A web page with third-party–hosted advertisement or user tracking is an example of content belonging to another organization but used on a different organiza-tion’s web page. With inputs from different applications, a given security boundary dis-appears. A web application that depends on content from many security boundaries is only as strong as the weakest link. If my intranet web application includes third-party scripts that are hosted outside my network, then external network attackers could gain access to my intranet application by modifying scripts my browser loads into the for-merly cozy security boundary of our intranet.
Following is an example of a common type of web application vulnerability that extends the security boundary of a site to be across multiple domains. These types of boundary extensions should be permitted only when there is a good business case and developers are intentionally accepting this risk. Often these boundary extensions are done without justification or consideration of the security impact.
Web pages are usually constructed from multiple files such as these:
• .html fi les that contain HTML content or framesets
• .js fi les fi lled with scripts used in rendering the page
• .gif, .png, and .jpg fi les for images
• .css fi les fi lled with style sheets
When a single web page is written, it references other resources for the browser to include when rendering it—for example, table layout and style information, images, and scripts to activate animations, perform calculations, or display advertisements.
Advertisements are often written by third parties and they are often hosted on third-party sites, some of which have a dubious reputation and are not trusted by reasonable users. A sample bit of page content that provides for ad inclusion might look like this:
<script language="JavaScript" src="http://Example.
AD_COMPANY.COM/adj/somesite/news/natworld/nation;ptype=s;
slug=lanausattys13mar13;rg=ur;ref=fooflecom;pos=left2;
sz=120x60;tile=3;ord=45113127?" type="text/javascript">
</script>
The pervious code loads a script from the ad company’s site into the context of the currently rendering page. Like any script loaded into the browser, the advertisement has access to the full content of the page as if it were loaded from the server currently being accessed. This includes access to the following:
• The cookies in this page, their values, and the ability to set them
• The content of this page, including any cross-site request forgery (CSRF) protection tokens in use
140
details, message contents, and so on
Web applications that include scripts from third-party domains give the code hosted on that domain access to the user’s formerly private view of the web site. This may allow advertisers or those who control their servers to peek at a customer’s financial data on their bank’s web site.
Another risk of including third-party scripts is the danger that those scripts will be compromised by a party even more malicious than adverting companies. An otherwise secure banking platform can be compromised if it included of scripts from a compromised site. Remember that scripts can be used to monitor keypress events or rewrite form controls; attackers may be able to log the keystrokes of users for passwords, credit card numbers, or other personal information.
To make matters worse, a few of the companies we trust to provide Secure Sockets Layer (SSL) security certificates often encourage their clients to put nice logos (such as images) on their sites. These logos attempt to assure users that the site is using a reputable vendor for its SSL certificate and therefore users should feel secure. For whatever reason, the certificate organizations often want to provide sites with a script to include rather than just a simple image, which would have far less impact on the security boundary of the application. Here’s an example:
<script
src="https://seal.verisign.com/getseal?host_name=www.webapplogin .com&size=S&use_flash=NO&use_transparent=NO&
lang=en"></script>
This creates a familiar seal:
Or it adds the following:
<script
src="https://siteseal.thawte.com/cgi/server/thawte_seal_generator .exe"></script>
This generates this graphic:
141
scripts are included. No need to compromise the fancy public key infrastructure (PKI) or break any SSL—a simple web server bug is a privacy disaster for every user of affected sites. Recall that some web server software has a patchy history. This violates the secu-rity principal of defense in depth, creates an obvious single point of failure, and reduces security to the lowest common denominator for users.
Now instead of considering a security-savvy SSL certificate authority, what if the script inclusion was from an online ad agency? How good would you feel about lower-ing your application security to the lesser of their or your protection? As advertisements are often a web site’s primary source of revenue, this is often a much more compelling business case. Adding images to make the uneducated feel a little better about the qual-ity of your SSL certificates is probably a bad securqual-ity tradeoff unless you target a very unusual demographic.
Another dangerous practice is inclusion of scripts for analyzing web site traffic. In-stead of just loading static content from the traffic analysis site, with the old counter-im-age trick, some sites load scripts that enable more sophisticated analysis. This analysis is achieved at the cost of trusting the analysis organization with the user’s session. Here is an example inclusion:
<script src="https://ssl.google-analytics.com/urchin.js"
type="text/javascript">
The inclusion of this “urchin” module allows Google to track user behavior on what-ever site hosts this code. While Google is certainly a trusted organization, the supposed tracker here may not be who users believe they are trusting when they enter their credit card or personal health information into applications, especially when SSL is used on a domain other than Google’s. Do you really think you made a good faith effort to protect user’s personal information if the pages that collect that information rely on Google’s good reputation for not including hostile scripts? How would your customers feel if they could figure it out? Patient privacy advocates should check out the NoScript plug-in for FireFox, which provides selective allowance of domains for script execution.
Assuming the connections are all SSL protected, exploiting any of these inclusions requires compromising the server from that the inclusions are sent (of course, non-SSL protected HTTP connections have no privacy, integrity, or source guarantees).
The examples shown in this case study are probably difficult to compromise. Even though these companies may have risky inclusion practices, they also have good reputations for protecting their own infrastructures, but nobody is perfect. Less savvy organizations such as those that have not invested in the security of their web products may be frequently exposing users to harmful attackers.
142
1. An attacker creates a script that sends the victim’s cookie used on the
vulnerable site (and the name of that site) to the attacker. This would allow the attacker to hijack the victim’s session.
2. The attacker then loads the Browser Exploitation Framework (BeEF at www .bindshell.net/tools/beef/, into the victim’s browser as if it were being
included from the vulnerable site. This would allow for more fl exible, real-time exploitation of victims, even on sites with the HTTPOnly cookie fl ag.
3. The attacker can then target information from the victim as the victim browses any particular site. Using the victim’s active session as well as the script’s access to the content would allow the attacker to eavesdrop and compromise all the information he or she wants.
In the Web 2.0 era, the Internet is not solely a collection of networks that are con-nected together, but also a collection of applications that are also concon-nected. Security is-sues from one application that is used to supply content to 30 other applications, which are then used by 200 additional applications, creates a web of security issues from a few single points of failure. Security professionals need to identify, justify, and minimize cross-domain script inclusion to avoid undercutting the security of their applications by eliminating or weakening important security barriers.