1. Introduction
The ‘Web Site Client Access Policy File Detection’ vulnerability means a ‘clientaccesspolicy.xml’ file exists on your web server. This XML file controls access for Microsoft Silverlight applications running outside of the website’s domain. Having this file, especially with broad permissions, can allow attackers to bypass security checks and potentially perform actions as if they were legitimate users. This could affect confidentiality, integrity, and availability of your web services.
2. Technical Explanation
The vulnerability occurs because the ‘clientaccesspolicy.xml’ file is present on a web server. Silverlight uses this file to determine which domains are trusted for cross-domain communication. An attacker can exploit an overly permissive policy, such as one allowing access from ‘*’, to make requests to your server that should not be allowed. This enables cross-site request forgery (CSRF) attacks or other malicious actions.
- Root cause: The presence of a ‘clientaccesspolicy.xml’ file with potentially insecure permissions.
- Exploit mechanism: An attacker crafts a malicious Silverlight application hosted on their domain, and the policy allows it to access resources on your server. For example, an unrestricted policy could allow reading sensitive data or modifying user accounts.
- Scope: Web servers hosting applications that use Microsoft Silverlight.
3. Detection and Assessment
You can confirm this vulnerability by checking for the existence of the ‘clientaccesspolicy.xml’ file on your web server. A thorough assessment involves reviewing its contents to identify any overly permissive rules.
- Quick checks: Use a web browser to navigate to
https://yourserver/clientaccesspolicy.xmland check if the file is accessible. - Scanning: Nessus vulnerability ID a4eeeaa2 can detect this issue. This is an example only, other scanners may also report it.
- Logs and evidence: Web server access logs will show requests for ‘clientaccesspolicy.xml’. Look for unusual user agents or IP addresses accessing the file.
curl -I https://yourserver/clientaccesspolicy.xml4. Solution / Remediation Steps
The best solution is to remove the ‘clientaccesspolicy.xml’ file if Silverlight is no longer used. If it’s required, carefully review and restrict its permissions.
4.1 Preparation
- Ensure you have access to restore the previous configuration if needed. A roll back plan is to restore the backed-up files.
- Changes should be approved by the security team or a senior IT administrator.
4.2 Implementation
- Step 1: Check if Silverlight is still in use on your web application. If not, delete the ‘clientaccesspolicy.xml’ file from the web server root directory.
- Step 2: If Silverlight is required, open the ‘clientaccesspolicy.xml’ file in a text editor.
- Step 3: Review each rule and restrict access to only trusted domains. Remove any wildcard (*) entries unless absolutely necessary and fully understood.
- Step 4: Save the modified ‘clientaccesspolicy.xml’ file back to the web server root directory.
- Step 5: Restart the web service.
4.3 Config or Code Example
Before
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from uri="*" />
</policy>
</cross-domain-access>
</access-policy>After
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from uri="https://trusteddomain.com" />
</policy>
</cross-domain-access>
</access-policy>4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this issue. Least privilege is key, limiting the impact of a compromised policy file. Input validation can also protect against malicious requests.
- Practice 1: Implement least privilege by restricting access in the ‘clientaccesspolicy.xml’ file to only trusted domains.
- Practice 2: Regularly review and update security policies, including those related to cross-domain communication.
4.5 Automation (Optional)
Automation is not typically suitable for this specific vulnerability due to the need for careful policy review.
5. Verification / Validation
Confirm the fix by checking that the ‘clientaccesspolicy.xml’ file no longer contains wildcard entries or only allows access from trusted domains. Test the Silverlight application to ensure it still functions correctly with the updated policy.
- Post-fix check: Use a web browser to view
https://yourserver/clientaccesspolicy.xmland verify that no ‘*’ entries are present. - Re-test: Re-run the curl command from step 3 of Detection and Assessment, confirming it does not return an unrestricted policy.
- Monitoring: Monitor web server access logs for requests to ‘clientaccesspolicy.xml’ from unexpected domains.
curl -I https://yourserver/clientaccesspolicy.xml6. Preventive Measures and Monitoring
Update your security baselines to include restrictions on cross-domain access policies. Implement checks in CI/CD pipelines to prevent overly permissive ‘clientaccesspolicy.xml’ files from being deployed.
- Baselines: Update a web server hardening baseline or policy to disallow wildcard entries in ‘clientaccesspolicy.xml’.
- Pipelines: Add static analysis checks to your CI/CD pipeline to scan for insecure configurations, including overly permissive cross-domain policies.
- Asset and patch process: Review configuration changes regularly as part of a vulnerability management program.
7. Risks, Side Effects, and Roll Back
Removing or modifying the ‘clientaccesspolicy.xml’ file could break Silverlight functionality if not done carefully. A roll back plan is to restore the original file from backup.
- Roll back: Restore the original ‘clientaccesspolicy.xml’ file from backup and restart the web service.
8. References and Resources
- Vendor advisory or bulletin: http://www.nessus.org/u?a4eeeaa2