the-web-application-hackers-handbook

526 Chapter 13 n Attacking Users: Other Techniques
HACK STEPS
You should always check for the /crossdomain.xml file on any web application
you are testing. Even if the application itself does not use Flash, if permission
is granted to another domain, Flash objects issued by that domain are
permitted to interact with the domain that publishes the policy.
n If the application allows unrestricted access (by specifying ), any other site can perform two-way
interaction, riding on the sessions of application users. This would allow
all data to be retrieved, and any user actions to be performed, by any
other domain.
n If the application allows access to subdomains or other domains used by
the same organization, two-way interaction is, of course, possible from
those domains. This means that vulnerabilities such as XSS on those
domains may be exploitable to compromise the domain that grants permission.
Furthermore, if an attacker can purchase Flash-based advertising
on any allowed domain, the Flash objects he deploys can be used to
compromise the domain that grants permission.
n Some policy files disclose intranet hostnames or other sensitive information
that may be of use to an attacker.
A further point of note is that a Flash object may specify a URL on the target
server from which the policy file should be downloaded. If a top-level policy
file is not present in the default location, the Flash browser tries to download a
policy from the specified URL. To be processed, the response to this URL must
contain a validly formatted policy file and must specify an XML or text-based
MIME type in the Content-Type header. Currently most domains on the web do
not publish a Flash policy file at /crossdomain.xml, perhaps on the assumption
that the default behavior with no policy is to disallow any cross-domain access.
However, this overlooks the possibility of third-party Flash objects specifying
a custom URL from which to download a policy. If an application contains any
functionality that an attacker could leverage to place an arbitrary XML file into
a URL on the application’s domain, it may be vulnerable to this attack.
The Same-Origin Policy and Silverlight
The same-origin policy for Silverlight is largely based on the policy that is
implemented by Flash. Silverlight objects have their origin determined by the
domain of the URL from which the object is loaded, not the URL of the HTML
page that loads the object.