Content Provider Conflict on the Modern Web
From the beginning of the World Wide Web, HTML pages have been composite documents, incorporating elements from multiple sources. Early pages mostly used text and images from a single web server; modern web pages, however, include content from multiple organizations. Some of these inclusions provide functional enhancements such as search services, blog ``trackback'' links, and video players; others supply the advertisements that are the economic foundation of much of the web.
This paper has two key contributions. The first is identifying the security threat caused inclusion of content from multiple content providers. This threat is made more dangerous by the assumption that content providers will interact only in safe ways (or not at all), as well as the assumption that most web pages are not in need of protections currently reserved for more complex web applications. Such assumptions can lead to inappropriate security decisions or design of systems which do not easily address the full scope of the problem. Because of the risks involved in such assumptions, the second contribution here is in outlining the requirements for a solution to this problem.
Most webpages are constructed using information from several sources. Sites that have content they want others to include will often give fragments of HTML code that users can put in their page. Although browsers still vary in how they render a page, this is the easiest way to assure that anyone who wants to can include this content, be it an image, a video, or something else.
In the most basic of HTML, there are many ways to include static content that will be the same every time the content is viewed. For example, video site YouTube generates code for people to embed video objects in their pages, as shown in Listing 1.
Here, the pertinent part is the object or embed tag which includes a flash video from YouTube into the page. Both tags are provided because some browsers only understand one or the other. The web browser reads the HTML, goes to get the video, and inserts this video into the page. It only inserts the video in where this tag was found. Images inserted with the img tag work the same way.
The path to content inclusion is shown in Figure 1. Here, you can see that the web page, combined with simple content such as the image shown, behaves in a predictable way, inserting the image where expected on the page.
Scripts are included as source, and often multiple scripts are included in the same page. Script sources are evaluated in the same context as the main page: the expectation is that the code of included scripts will not interfere with each other. Multiple inclusions work because developers respect conventions; the browser enforces no separation.
To summarize, the current model for web document creation allows code and data to be included from several sources. The assumption is that all code is equally trusted and should be integrated with the same rights and privileges as the document that caused it to be included. Controlled interaction between sources--other than the same origin policy--is not provided. This inclusion of code and data can be thought of as a type of code mobility, a form of distributed computing. As with other code mobility systems, inappropriate trust relationships lead to a number of potential problems. We discuss these problems in the context of content provider conflict below.
While it is likely that virtually all current external content providers are playing ``nicely'' with each other, we should not expect that those relationships will remain so civilized. Indeed, as the Sony rootkit debacle showed , major corporations are perfectly capable of using malicious software to further their interests.
Note that these are the same mechanisms used to generate customized advertisements and to gather statistics on site visitors. The only difference here is the subject of observation.
Of course, since there is no restriction on A's access to the page, A could choose to modify other parts of X. A could cause B to display inappropriate advertisements by inserting (hidden) content into the page. More sophisticated content-based attacks are also possible such as content censorship; to avoid detection, however, they would need to be very constrained and targeted.
This section attempts to create a set of goals for web security solutions addressing the problem of content provider conflict. There are 4 goals: ease of use for all web page creators, clear adoption path, isolation between content providers, and flexibility for future innovation in web applications.
10] rely heavily upon skilled web programmers who could produce secure web pages. This makes sense when you are considering securing complex web applications, which are often created by skilled programmers. However, we have seen that there is risk any time code from multiple providers is included on a page. Thus, any blog that contains cut and pasted ad code, videos, etc. could be at risk, and many people who use the simple cut and pasted code are not programmers at all.
The ideal solution to content provider conflict must take this common use case into account. For example, one could provide secured code which can be cut and pasted with the code fragments currently in use, or perhaps encourage tools which automatically generate more secure code. Or, perhaps, the solution lies in involving the page creator as little as possible since their skill set and preferred tools cannot be predicted.
Currently there is an ongoing battle between advertisers and criminals. Advertisers regularly lose money to click fraud schemes in which criminals fake legitimate user behavior , and research indicates that some click fraud strategies can be extremely subtle and hard to detect . Criminals are also taking advantage of the access ad servers have to regular users; indeed, even major companies such as DoubleClick  and Microsoft  have been tricked into distributing advertisements containing malware. In this environment it is clear that users have reason to be wary of ad servers. What we have argued here is that content providers such as ad servers need to be wary of each other as well.
Several researchers have proposed secure mechanisms for building web mashups. The goal of such systems is to achieve something equivalent to Figure 4b. Here, code and data from different sources are loaded into separate contexts; they neither share the same DOM objects, nor do they share the same namespace. Using the example from Section III, a function foo would be defined twice, once in the context from A and once in the context from B. For A and B to communicate, they must use well-defined communication channels using mutually agreed-upon protocols. Note that this architecture is virtually identical to that used by most distributed computing platforms.
When looking at the potential for conflict between external content providers, we do not mean to imply that we expect most providers to engage in open warfare on the web; instead, we are simply pointing out that there are conflicting agendas, and there is nothing to prevent those conflicts from manifesting as real attacks. While one type of content provider conflict, click fraud, is a significant problem, currently it is only perpetrated by known criminals. What happens, though, when legitimate businesses go bad?
As with most security problems, a point solution is not the answer; rather, layers of defense are required. Some defenses, such as code obfuscation and tamper resistance, could be deployed by the content providers themselves. Such measures, however, are partial at best; if conflict were to become common, an arms race would follow that would, at a minimum, degrade the experience of regular web users through broken and slowly executing web pages.
Work on more secure web mashups is an important step forward. However, the requirements for mashups and for content providers are different: where mashups require channels of communication between content in different frames, many content providers advertisements need to be able to analyze or even change the contents of a page in order to provide their services. We believe that protections from interactions between external content providers is an important area for future work.
We thank the members of Carleton Computer Security Laboratory and the anonymous reviewers for their suggestions.
This work was supported by the Canada's National Sciences and Engineering Research Council (NSERC) through their Postgraduate Scholarship program (TO) and Discovery Grant program (AS & TW). In addition, Research in Motion (RIM) has provided support for our research in Web security.
- ``Symantec internet security threat report,'' Symantec, Tech. Rep. XII, September 2007.
- CERT Coordination Center, ``Frequently asked questions about malicious web scripts redirected by web sites,'' CERT, Tech. Rep., 2004. [Online]. Available: http://www.cert.org/tech_tips/malicious_code_FAQ.html
- M. Gandhi, M. Jakobsson, and J. Ratkiewicz, ``Badvertisements: Stealthy click-fraud with unwitting accessories,'' vol. 1, no. 2.Taylor & Francis, 2006, pp. 131-142.
- L. Gong, M. Mueller, H. Prafullchandra, and R. Schemers, ``Going beyond the sandbox: An overview of the new security architecture in the Java Development Kit 1.2,'' in USENIX Symposium on Internet Technologies and Systems, 1997.
- D. Goodin, ``Doubleclick caught supplying malware-tainted ads,'' The Register, November 13 2007.
- J. Howell, C. Jackson, H. Wang, and X. Fan, ``Mashupos: Operating system abstractions for client mashups,'' in Proceedings of the Workshop on Hot Topics in Operating Systems, May 2007.
- InformAction, ``Noscript.'' [Online]. Available: http://noscript.net/
- N. Ives, ``Web marketers fearful of fraud in pay-per-click,'' The New York Times, March 3 2005.
- C. Jackson and H. J. Wang, ``Subspace: Secure cross-domain communication for web mashups,'' in Proceedings of the 16th International World Wide Web Conference (WWW2007), Banff, Alberta, May 8-12 2007.
- N. Jovanovic, E. Kirda, and C. Kruegel, ``Preventing cross site request forgery attacks,'' in 2nd IEEE Communications Society International Conference on Security and Privacy in Communication Networks (SecureComm).Baltimore, MD: IEEE Computer Society Press, August 2006.
- F. D. Keukelaere, S. Bhola, M. Steiner, S. Chari, and S. Yoshihama, ``Smash: Secure cross-domain mashups on unmodified browsers,'' IBM Research, Tokyo Research Laboratory, IBM Japan, Ltd., Tech. Rep. RT0742, June 11 2007.
- E. Kirda, C. Kruegel, G. Vigna, and N. Jovanovic, ``Noxes: A client-side solution for mitigating cross site scripting attacks,'' in The 21st ACM Symposium on Applied Computing (SAC 2006), Security Track, Dijon, France, April 2006.
- T. Oda, G. Wurster, P. V. Oorschot, and A. Somayaji, ``SOMA: Mutual approval for included content in web pages,'' School of Computer Science, Carleton University, Tech. Rep. TR-08-07, 2008.
- N. Provos, D. McNamee, P. Mavrommatis, K. Wang, and N. Modadugu, ``The ghost in the browser: Analysis of web-based malware,'' Workshop on Hot Topics in Understanding Botnets (HotBots), April, vol. 10, 2007.
- N. Provos, P. Mavrommatis, M. A. Rajab, and F. Monrose, ``All your iframes point to us,'' Google, Tech. Rep. provos-2008a, February 4 2008.
- J. Reimer, ``Microsoft apologizes for serving malware,'' ars technica, February 21 2007.
- C. Reis, S. Gribble, and H. Levy, ``Architectural principles for safe web programs,'' in Sixth Workshop on Hot Topics in Networks (HotNets) 2007, 2007.
- C. Reis, J. Dunagan, H. J. Wang, O. Dubrovsky, and S. Esmeir, ``Browsershield: Vulnerability-driven filtering of dynamic html,'' in IEEE Symposium on Security and Privacy, Oakland, CA, May 2006.
- B. Schneier, ``Real story of the rogue rootkit,'' Wired, 2005.
- P. Vogt, F. Nentwich, N. Jovanovic, C. Kruegel, E. Kirda, and G. Vigna, ``Cross site scripting prevention with dynamic data tainting and static analysis,'' in 14th Annual Network and Distributed System Security Symposium (NDSS 2007), San Diego, CA, February 2007.
Terri Oda 2008-06-16