1. Introduction
Insecure Cross-Domain Policy (allow-access-from) occurs when a website’s `crossdomain.xml` file is configured too permissively, allowing any domain to access its resources. This can allow malicious websites to read sensitive data from your server. Systems using Silverlight are usually affected. A successful exploit could lead to information disclosure impacting confidentiality.
2. Technical Explanation
The browser security model prevents cross-domain access by default. URL policy files like `crossdomain.xml` override this protection, granting permissions for reading data. When a domain is specified in `crossdomain.xml`, the site allows servers within that domain to obtain documents from its server. The vulnerability arises when using a wildcard (“*”) which opens the server to all domains. An attacker could host a malicious web page and use JavaScript to make cross-domain requests, potentially stealing data from your website.
- Root cause: Overly permissive `crossdomain.xml` configuration allowing access from any domain using a wildcard (“*”).
- Exploit mechanism: An attacker hosts a malicious webpage that uses JavaScript to request resources from the vulnerable server, bypassing the same-origin policy.
- Scope: Websites deploying Silverlight and using a `crossdomain.xml` file with unrestricted permissions are affected.
3. Detection and Assessment
You can confirm vulnerability by checking your web server for the presence of an overly permissive `crossdomain.xml` file. A thorough method involves reviewing the contents of the file to identify wildcard entries.
- Quick checks: Use a web browser or command-line tool like `curl` to check if a `crossdomain.xml` file exists in your website’s root directory (e.g., `www.example.com/crossdomain.xml`).
- Scanning: Nessus plugin ID 31789 can identify insecure cross-domain policy files. This is an example only, and may require updates.
- Logs and evidence: Web server logs might show requests originating from unexpected domains attempting to access resources protected by the `crossdomain.xml` file.
curl https://www.example.com/crossdomain.xml4. Solution / Remediation Steps
Carefully evaluate which sites need cross-domain access and restrict permissions accordingly. Implement the following steps to fix this issue.
4.1 Preparation
- Ensure you have a list of legitimate domains that require cross-domain access. A roll back plan involves restoring the original `crossdomain.xml` file from backup.
- Change windows may be needed depending on your organisation’s policies. Approval should be sought if this affects multiple services.
4.2 Implementation
- Step 1: Access the server where the `crossdomain.xml` file is located.
- Step 2: Open the `crossdomain.xml` file in a text editor.
- Step 3: Remove or modify the wildcard (“*”) entry to specify only trusted domains.
- Step 4: Save the changes to the `crossdomain.xml` file.
- Step 5: Restart any affected services if necessary.
4.3 Config or Code Example
Before
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>After
<cross-domain-policy>
<allow-access-from domain="https://trusted.example.com" />
<allow-access-from domain="https://another.trusted.example.net" />
</cross-domain-policy>4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this issue. Least privilege is key, limiting access only to necessary domains. Secure configuration management ensures consistent and correct settings. Patch cadence helps address known vulnerabilities in Silverlight or related components.
- Practice 1: Implement least privilege by granting cross-domain access only to trusted domains.
- Practice 2: Use secure configuration management practices to ensure the `crossdomain.xml` file is correctly configured and monitored for changes.
4.5 Automation (Optional)
Automation may be possible using scripting tools like PowerShell or Ansible to update the `crossdomain.xml` file across multiple servers. Exercise caution when automating configuration changes.
# Example PowerShell script (use with care!)
# Get-Content -Path "C:inetpubwwwrootcrossdomain.xml" | Where-Object { $_ -notmatch 'domain="*"' } | Set-Content -Path "C:inetpubwwwrootcrossdomain.xml"5. Verification / Validation
Confirm the fix by checking that the `crossdomain.xml` file no longer contains wildcard entries. Re-test using a browser developer console to verify cross-domain access is restricted.
- Post-fix check: Use `curl https://www.example.com/crossdomain.xml` and confirm the output does not include `
`. - Re-test: Attempt to make a cross-domain request from an untrusted domain using JavaScript in a browser developer console. The request should be blocked.
- Monitoring: Monitor web server logs for any unexpected cross-domain access attempts.
curl https://www.example.com/crossdomain.xml6. Preventive Measures and Monitoring
Update security baselines to include restrictions on `crossdomain.xml` configurations. Implement checks in CI or deployment pipelines to prevent overly permissive settings from being deployed. Establish a regular patch review cycle for Silverlight and related components. For example, use CIS benchmarks to define secure configuration standards.
- Baselines: Update security baselines to include restrictions on `crossdomain.xml` configurations.
- Asset and patch process: Review Silverlight patches regularly, as this is an older technology with limited support.
7. Risks, Side Effects, and Roll Back
- Risk or side effect 1: Legitimate applications relying on unrestricted cross-domain access may stop functioning.
- Risk or side effect 2: Incorrectly configured trusted domains could lead to unintended access restrictions.
- Roll back: Restore the original `crossdomain.xml` file from backup and restart any affected services.
8. References and Resources
- Vendor advisory or bulletin: http://blogs.adobe.com/stateofsecurity/2007/07