Scribd Logo
Upload

Welcome to Scribd!

  • 12 views

    Crossdomain XML

    Uploaded by

    tarun.cyber14
    The document discusses cross-domain policy files in Flash and Silverlight that define allowed domains for cross-domain requests. It warns that using wildcards to specify allowed domains poses security risks by allowing untrusted domains to potentially attack users. It recommends removing any inappropriate entries from cross-domain policy files to prevent attackers from stealing private information or sending malicious requests on behalf of victims.

    Copyright:

    © All Rights Reserved
    Download as TXT, PDF, TXT or read online from Scribd

    Crossdomain XML

    Uploaded by

    tarun.cyber14
    12 views3 pages
    The document discusses cross-domain policy files in Flash and Silverlight that define allowed domains for cross-domain requests. It warns that using wildcards to specify allowed domains poses security risks by allowing untrusted domains to potentially attack users. It recommends removing any inappropriate entries from cross-domain policy files to prevent attackers from stealing private information or sending malicious requests on behalf of victims.

    Original Title

    Crossdomain.xml

    Copyright

    © © All Rights Reserved

    Available Formats

    TXT, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document discusses cross-domain policy files in Flash and Silverlight that define allowed domains for cross-domain requests. It warns that using wildcards to specify allowed domains poses security risks by allowing untrusted domains to potentially attack users. It recommends removing any inappropriate entries from cross-domain policy files to prevent attackers from stealing private information or sending malicious requests on behalf of victims.

    Copyright:

    © All Rights Reserved
    Download as TXT, PDF, TXT or read online from Scribd
    Download as txt, pdf, or txt
    12 views3 pages

    Crossdomain XML

    Uploaded by

    tarun.cyber14
    The document discusses cross-domain policy files in Flash and Silverlight that define allowed domains for cross-domain requests. It warns that using wildcards to specify allowed domains poses security risks by allowing untrusted domains to potentially attack users. It recommends removing any inappropriate entries from cross-domain policy files to prevent attackers from stealing private information or sending malicious requests on behalf of victims.

    Copyright:

    © All Rights Reserved
    Download as TXT, PDF, TXT or read online from Scribd
    Download as txt, pdf, or txt
    of 3

    hola,

    bug- flash cross domain policy

    A cross-domain policy file ("crossdomain.xml" in Flash and "clientaccesspolicy.xml"


    in Silverlight) defines a list of domains from which a server is allowed to make
    cross-domain requests. When making a cross-domain request, the Flash or Silverlight
    client will first look for the policy file on the target server. If it is found,
    and the domain hosting the application is explicitly allowed to make requests, the
    request is made.
    Therefore, if a cross-domain policy file includes domains that should not be
    trusted, such as when using wildcards, then the application could be attacked by
    these untrusted domains.
    An overly permissive policy file allows many of the same attacks seen in Cross-Site
    Scripting (CWE-79). Once the user has executed a malicious Flash or Silverlight
    application, they are vulnerable to a variety of attacks. The attacker could
    transfer private information, such as cookies that may include session information,
    from the victim's machine to the attacker. The attacker could send malicious
    requests to a web site on behalf of the victim, which could be especially dangerous
    to the site if the victim has administrator privileges to manage that site.
    In many cases, the attack can be launched without the victim even being aware of
    it.

    The application publishes a Flash cross-domain policy which uses a wildcard to


    specify allowed domains. Using a wildcard to specify allowed domains means that any
    domain matching the wildcard expression can perform two-way interaction with this
    application. You should only use this policy if you fully trust every possible web
    site that may reside on a domain which matches the wildcard expression.

    The Flash cross-domain policy controls whether Flash client components running on
    other domains can perform two-way interaction with the domain that publishes the
    policy. If another domain is allowed by the policy, then that domain can
    potentially attack users of the application. If a user is logged in to the
    application, and visits a domain allowed by the policy, then any malicious content
    running on that domain can potentially gain full access to the application within
    the security context of the logged in user.
    Even if an allowed domain is not overtly malicious in itself, security
    vulnerabilities within that domain could potentially be leveraged by a third-party
    attacker to exploit the trust relationship and attack the application that allows
    access. Any domains that are allowed by the Flash cross-domain policy should be
    reviewed to determine whether it is appropriate for the application to fully trust
    both their intentions and security posture.
    Any inappropriate entries in the Flash cross-domain policy file should be removed.

    step to reproduce

    request

    GET /crossdomain.xml HTTP/1.1


    Host: admin.foxycart.com
    User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101
    Firefox/78.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Connection: close
    Cookie: PHPSESSID=uu4p4nsjl1ncksurlttdf526a0;
    csrf_token=8ourOMPsTjFsqhOgqS4xZHV4n3kHrK7PSlJeaNYsPyI%3D;
    optimizelyEndUserId=oeu1595152425693r0.3228238258062298; optimizelySegments=%7B
    %22234346863%22%3A%22direct%22%2C%22234587425%22%3A%22false%22%2C%22234696064%22%3A
    %22ff%22%7D; optimizelyBuckets=%7B%7D; optimizelyPendingLogEvents=%5B%5D;
    __utma=91412365.448719536.1595152427.1595152427.1595152427.1;
    __utmb=91412365.1.10.1595152427; __utmc=91412365;
    __utmz=91412365.1595152427.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
    __utmt=1; foxyio-_zldp=QOZUuxNcWyxo5jIXrhVjVSmZVon0ahW31DfDE9AH
    %2F5%2B0qAL4THkNwf2s3jrCYykDodoRkLyJC2Y%3D; foxyio-_zldt=32f26e6f-3894-4454-a22e-
    961d7e4e5629
    Upgrade-Insecure-Requests: 1
    Cache-Control: max-age=0

    response

    HTTP/1.1 200 OK
    Date: Sun, 19 Jul 2020 10:10:04 GMT
    Content-Type: text/xml
    Connection: close
    Server: nginx
    Last-Modified: Thu, 27 Aug 2015 22:17:13 GMT
    Content-Length: 112

    <?xml version="1.0"?>
    <cross-domain-policy>
    <allow-access-from domain="*.foxycart.com" />
    </cross-domain-policy>

    POC
    These cross-domain policy files mean to allow Flash and Silverlight applications
    hosted on other domains to access its data:

    Flash crossdomain.xml (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>

    Silverlight clientaccesspolicy.xml

    <?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>
    These entries are far too permissive, allowing any Flash or Silverlight application
    to send requests. A malicious application hosted on any other web site will be able
    to send requests on behalf of any user tricked into executing it.

    impact
    An attacker may be able to bypass the web browser's same-origin policy. An attacker
    can exploit the weakness to manipulate or steal cookies, create requests that can
    be mistaken for those of a valid user, compromise confidential information, or
    execute malicious code on the end user systems for a variety of nefarious purposes.
    Other damaging attacks include the disclosure of end user files, installation of
    Trojan horse programs, redirecting the user to some other page or site, running
    ActiveX controls (under Microsoft Internet Explorer) from sites that a user
    perceives as trustworthy, and modifying presentation of content.

    You might also like