This call will return the following formatted data that can be subsequently processed by the third-party application to compute statistics or store in a database for later use.

<user> <id>57142771</id> <name>Elie Bursztein</name> <screen_name>elie</screen_name> <location>Palo Alto</location> <url> http://elie.im</url> <protected>false</protected> … <text> Second time I see the SMS fuzzing talk, I am still loving it :) #woot </text> … </user>

The problem here lies in the fact that there is implicit trust between the third-party application and the cloud service. Third-party application developers assume the cloud service provides “safe” data. However, defining what safe data means is far from obvious and each cloud service has its own sanitization policy which is often not explicitly documented. This inconsistency between expected data and supplied data can result in RXCS. We give two examples.

5. 1. facebook RXcS

Facebook escapes at display time which means that the data provided to third-party applications is not escaped. Facebook’s terms of service say that third-party applications are not supposed to directly output the data fetched from the API but rather use the Facebook output functions. Similarly, applications are not supposed to store any user data. However, it is likely that some applications will display the data or store it, even if Facebook may monitor API usage to prevent terms of service violations.

To give an example, we point out that attacking a vulnerable third-party application can be done by noting that all the profile details from interests to music and movies are not escaped. Consequently, it is sufficient to add the <script> tag to them to get that text reflected to an application. In theory, this might be used to bypass Facebook security policies. The source of the problem is that Facebook trusts third-party applications to properly handle API data, while application developers often make assumptions about the safety of that data.

Suppose you have an application that displays information about Facebook users’ favorite movies. It is sufficient to add malicious payload in the movie profile data: this payload can then get reflected to all Facebook users that use the application.

5. 2. Twitter RXcS

Twitter has the opposite filtering policy compared to Facebook: escaping is performed at input time so all data

112 communicaTionS of The acm | auGust 2010 | Vol. 53 | no. 8

provided to third-party applications is HTML escaped. If an application wants to deal with “raw data” it has to unescape the data before processing it. Of course, when the application wants to output the data, it has to reescape the data in its own way. This unescape, reescape process is tedious and error-prone. Indeed, it is not difficult to find a Twitter application that is vulnerable to RXCS injection. In Figure 10, one such application is asked to search for a string, which is the label of a message planted by the attacker. When the application finds the string (and thus the planted message), it shows the message in the browser after processing it and the embedded payload is inadvertently executed.

As one can see, interactions with cloud services rely on many assumptions that are not properly formalized. In particular, understanding the trust model behind this exchange and how to combine filtering policies are open questions that we want to address in future work.

6. DefenSeS aGainST XcS

One defense against XCS is to ensure that all data sent to the user’s browser is properly sanitized. In principle, static analyzers can perform flow analysis to detect potential XCS. 1, 14 This approach must taint all input channels into the Web application, including all persistent data on the device, and raise an alarm if tainted data is displayed in a Web page without first being sanitized. Tracking data life cycle can easily miss some XCS channels or fail to taint XCS content. Another popular XSS defense, used by Twitter for instance, is to sanitize all user data at input time, before it is written to persistent storage at the site. This is unlikely to mitigate an XCS vulnerability because the malicious content is injected via a non-Web channel, which usually does not sanitize for Web exploits. Moreover, this defense fails to work directly on non-Web raw data, such as plain text event logs. This is problematic if these data are also used by other applications that are not Web based such as a back-end statistics analyzer or an IDS.

In our original paper on XCS, 3 we proposed a defense called SiteFirewall, and compared it to other current developments in Web security. SiteFirewall, CSP, SOMA, and other mechanisms generally attempt to block a Web site running in a browser context from executing operations that involve other Web sites and could potentially either access or exfiltrate private data.

While recent work on XCS defenses has focused primarily on the browser, we have only begun to address some inherently server-side problems. First, device vendors must

figure 10. a Twitter third-party application attack illustrated.