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.
Second time I see the SMS fuzzing talk,
I am still loving it :) #woot
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
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.