CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains

Description:
The product uses a web-client protection
         mechanism such as a Content Security Policy (CSP) or
         cross-domain policy file, but the policy includes untrusted
         domains with which the web client is allowed to
         communicate.

Extended Description:
If a cross-domain policy file includes domains
            that should not be trusted, such as when using wildcards
            under a high-level domain, then the application could be
            attacked by these untrusted domains. In many cases, the
            attack can be launched without the victim even being aware
            of it.

Affected languages: Not Language-Specific
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-863, CWE-923, CWE-183

Consequences:
  - Confidentiality: Execute Unauthorized Code or Commands

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Define a restrictive Content Security Policy [REF-1486] or cross-domain policy file.
  - [Architecture and Design] Avoid using wildcards in the CSP / cross-domain policy file. Any domain matching the wildcard expression will be implicitly trusted, and can perform two-way interaction with the target server.
  - [Architecture and Design] For Flash, modify crossdomain.xml to use meta-policy options such as 'master-only' or 'none' to reduce the possibility of an attacker planting extraneous cross-domain policy files on a server.

Demonstrative examples:
These cross-domain policy files mean to allow Flash and Silverlight applications hosted on other domains to access its data:
Flash crossdomain.xml :
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd"> <allow-access-from domain="*.example.com"/> <allow-access-from domain="*"/> </cross-domain-policy>
<?xml version="1.0" encoding="utf-8"?> <access-policy> <cross-domain-access> <policy> <allow-from http-request-headers="SOAPAction"> <domain uri="*"/> </allow-from> <grant-to> <resource path="/" include-subpaths="true"/> </grant-to> </policy> </cross-domain-access> </access-policy>

Real-world examples:
  - CVE-2012-2292: Product has a Silverlight cross-domain policy that does not restrict access to another application, which allows remote attackers to bypass the Same Origin Policy.
  - CVE-2014-2049: The default Flash Cross Domain policies in a product allows remote attackers to access user files.
  - CVE-2007-6243: Chain: Adobe Flash Player does not sufficiently restrict the interpretation and usage of cross-domain policy files, which makes it easier for remote attackers to conduct cross-domain and cross-site sc
  - CVE-2008-4822: Chain: Adobe Flash Player and earlier does not properly interpret policy files, which allows remote attackers to bypass a non-root domain policy.
  - CVE-2010-3636: Chain: Adobe Flash Player does not properly handle unspecified encodings during the parsing of a cross-domain policy file, which allows remote web servers to bypass intended access restrictions via un