Datasheet

34 Part I  Overview of Commerce
In the context of cloud computing, for the applications whose intent is not to
be malicious the, top threats appear to be the following. The list of attack vec-
tors is not ranked in any specific order:
XSS (Cross Site Scripting):

Starting point for many of the attacks listed
here. XSS vulnerabilities can be exploited to inject whatever code is desired.
Proper input validation would prevent this.
CSRF

(Cross Site Request Forgery): Failing to ensure that apps are immune
to CSRF-based attacks could leave the cloud computing application and
its users wide open to “drive-by” attacks that make use of whatever func-
tionality exists in the particular application (which may be quite elevated)
all without the users’ awareness. Sending a randomized user-specific
token with every request for the app to check would help prevent CSRF.
However, any application that is vulnerable to XSS is also vulnerable to
CSRF because one can glean the mentioned token via XSS.
Open redirects:

If an application were vulnerable to XSS-based attacks,
redirecting the user’s browser (to a spoofed sign-in page, for example)
would be simple if the app is vulnerable to persistent XSS, and a bit more
difficult with reflected XSS (the user would have to visit a specially crafted
URL that contains the redirection payload in it).
Malware drops/drive-bys:

Leveraging an XSS vulnerability, malicious
code can be forced upon a user and exploit a vulnerability in the browser,
browser plug-in, and so on to drop a piece of malware on the user’s
machine, and without the user’s awareness. iFrame attacks (aka iFrame
hijacking) are only one mechanism to mount this exploit and are a vector
of choice for attackers. Malware is wrapped in JavaScript, gets past the
defenses, unpacks through the browser, escapes the iFrame-jailhouse, and
compromises the system without anything knowing it went by.
Malicious links:

Using XSS, a malicious user could embed a link (i.e.
<a href=”...”> ) to a malicious site that executes any of the previously
mentioned attacks.
Third-party availability:

If some parts of an application reside off the
protected portion of your cloud computing infrastructure, or leverage
off-infrastructure resources, there will then be reliance on the availability/
integrity of the third party’s infrastructure.
It must be noted that most of the attacks in the preceding list exploit holes
in the applications themselves. In other words, the application is not meant
to be malicious. These same attacks would be significantly easier to execute if
the developer of the application intended for the application to be malicious, of
course, and are a very real possibility if an untrusted developer is allowed to
write applications for your cloud computing and e-commerce infrastructure.
624463c01.indd 34 3/29/11 2:26:37 AM