How to remediate – Missing Permissions Policy

1. Introduction

The vulnerability ‘Missing Permissions Policy’ means a website isn’t controlling browser feature access within its own pages and embedded content. This can allow malicious websites to use features they shouldn’t, potentially stealing data or performing actions on your behalf. Websites are usually affected. A missing policy could lead to reduced confidentiality, integrity, and availability of user data and system functions.

2. Technical Explanation

Permissions Policy lets a website restrict browser features within its own frame and iframes it includes. Without this policy in place, websites are vulnerable to abuse by content they load. An attacker could include an iframe from a malicious source that uses restricted features like geolocation or camera access. The preconditions for exploitation are simply the user visiting a website without a correctly configured Permissions Policy.

• Root cause: Absence of the ‘Permissions-Policy’ HTTP header on the web server response.
• Exploit mechanism: An attacker hosts malicious content in an iframe that attempts to use restricted browser features. If the target site lacks a Permissions Policy, the browser allows access.
• Scope: All websites served over HTTP and HTTPS are affected if they do not define a Permissions Policy.

3. Detection and Assessment

You can confirm whether a system is vulnerable by checking for the presence of the ‘Permissions-Policy’ header in your website’s responses. A quick check involves using browser developer tools, while thorough assessment requires reviewing all web server configurations.

• Quick checks: Use your browser’s developer tools (Network tab) to inspect HTTP headers when visiting your website. Look for the ‘Permissions-Policy’ header.
• Scanning: Security scanners like OWASP ZAP or Burp Suite can detect missing Permissions Policy headers. These are examples only, and results should be verified.
• Logs and evidence: Web server access logs will show all HTTP responses. Analyse these to see if the ‘Permissions-Policy’ header is present for each request.

curl -I https://yourwebsite.com | grep "Permissions-Policy"

4. Solution / Remediation Steps

To fix this issue, you need to configure the ‘Permissions-Policy’ HTTP header on your website. This is done through your web server configuration or application code.

4.1 Preparation

• Ensure you have access to modify the web server configuration files (e.g., Apache .htaccess, Nginx conf). A roll back plan is to revert the configuration file to its previous state.
• A change window may be needed depending on your environment and approval process.

4.2 Implementation

1. Step 1: Edit your web server’s configuration file (e.g., .htaccess, conf).
2. Step 2: Add the ‘Permissions-Policy’ header with a suitable policy definition. See example below.
3. Step 3: Save the changes to the configuration file.
4. Step 4: Restart your web server or reload the configuration for the changes to take effect.

4.3 Config or Code Example

Before

# No Permissions-Policy header present

After

Header always set Permissions-Policy "geolocation=(),camera=()"

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact if exploited, and secure headers provide an additional layer of defence.

• Practice 1: Implement least privilege by restricting browser features only as needed.
• Practice 2: Use secure headers to control browser behaviour and mitigate potential attacks.

4.5 Automation (Optional)

# Example Ansible task to set Permissions-Policy header in Nginx configuration
- name: Set Permissions-Policy header in Nginx config
  lineinfile:
    path: /etc/nginx/nginx.conf
    regexp: '^http {'
    insertafter: '^http {'
    line: '  add_header Permissions-Policy "geolocation=(),camera=()" always;'

5. Verification / Validation

Confirm the fix by checking for the presence of the ‘Permissions-Policy’ header in your website’s responses using browser developer tools or curl. A negative test involves attempting to use a restricted feature on the site.

• Post-fix check: Run `curl -I https://yourwebsite.com | grep “Permissions-Policy”` and confirm the header is present in the output.
• Re-test: Repeat the quick check from Section 3 to verify the ‘Permissions-Policy’ header is now visible.
• Monitoring: Monitor web server logs for any errors related to the new header configuration.

curl -I https://yourwebsite.com | grep "Permissions-Policy"

6. Preventive Measures and Monitoring

Update security baselines or policies to include a requirement for defining Permissions Policy. Add checks in your CI/CD pipeline to ensure the header is present during deployment. For example, use SAST tools to scan configuration files.

• Baselines: Update your website security baseline to require a defined Permissions Policy.
• Pipelines: Integrate static analysis (SAST) into your CI/CD pipeline to check for missing headers in web server configurations.
• Asset and patch process: Review configuration changes regularly as part of your asset management process.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Blocking necessary browser features could cause website errors or usability issues.
• Risk or side effect 2: Overly restrictive policies may impact third-party integrations.
• Roll back:
  1. Step 1: Restore the previous version of your web server configuration file.
  2. Step 2: Restart your web server or reload the configuration.

8. References and Resources

• Vendor advisory or bulletin: N/A
• NVD or CVE entry: N/A
• Product or platform documentation relevant to the fix: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy
• If helpful, a benchmark or standard that maps to the fix (for example, a specific CIS control). Only include if it fits: N/A