1. Introduction
The vulnerability is a missing ‘X-Content-Type-Options’ header in HTTP responses. This means browsers may attempt to guess the content type of files, potentially leading to Cross-Site Scripting (XSS) attacks if the server’s declared content type is incorrect. Websites serving any kind of file are usually affected. A successful exploit could allow an attacker to inject malicious scripts into a user’s browser, impacting confidentiality, integrity and availability.
2. Technical Explanation
The root cause is the absence of the ‘X-Content-Type-Options’ header in the server’s HTTP response. This allows browsers to use MIME sniffing to determine the content type, overriding the server’s declaration. An attacker could upload a file with an incorrect content type; if the browser incorrectly identifies it, malicious code within the file may execute.
- Root cause: missing ‘X-Content-Type-Options’ header in HTTP responses.
- Exploit mechanism: An attacker uploads a file disguised as a different content type. The browser MIME-sniffs the file and executes malicious code if it misidentifies the content type.
- Scope: All web servers and applications that do not explicitly set the ‘X-Content-Type-Options’ header are affected.
3. Detection and Assessment
You can confirm vulnerability by checking HTTP responses for the missing header, or using a scanner to identify this issue.
- Quick checks: Use your browser’s developer tools (Network tab) to inspect the response headers of various web pages on the server.
- Scanning: Nessus plugin ID 10643 and OpenVAS scan script http_x_content_type_options are examples that can detect this issue.
- Logs and evidence: Web server access logs may not directly show this vulnerability, but examining response headers manually is the best approach.
curl -I https://example.com4. Solution / Remediation Steps
Configure your web server to include the ‘X-Content-Type-Options’ header with a value of ‘nosniff’. This prevents browsers from MIME-sniffing responses.
4.1 Preparation
- Ensure you have access to the web server’s configuration files. Roll back by removing the added header if issues occur.
- A change window may be required depending on service criticality, with approval from the IT security team.
4.2 Implementation
- Step 1: Edit your web server’s main configuration file (e.g., Apache’s httpd.conf or Nginx’s nginx.conf).
- Step 2: Add the following line to the appropriate section of the configuration file, typically within the virtual host definition:
Header always set X-Content-Type-Options "nosniff". - Step 3: Save the changes and restart your web server.
4.3 Config or Code Example
Before
<VirtualHost *:80>
ServerName example.com
DocumentRoot /var/www/example.com
</VirtualHost>After
<VirtualHost *:80>
ServerName example.com
DocumentRoot /var/www/example.com
Header always set X-Content-Type-Options "nosniff"
</VirtualHost>4.4 Security Practices Relevant to This Vulnerability
Secure headers are a key practice in preventing this issue, alongside regular security configuration reviews and patch management.
- Practice 1: Implement secure HTTP headers as a standard practice across all web applications.
- Practice 2: Regularly review server configurations to ensure compliance with security best practices.
4.5 Automation (Optional)
# Example Ansible task to set the header in Apache configuration
- name: Set X-Content-Type-Options header in Apache config
lineinfile:
path: /etc/httpd/conf/httpd.conf
regexp: '^Header always set'
line: 'Header always set X-Content-Type-Options "nosniff"'
state: present
notify: Restart Apache5. Verification / Validation
Confirm the fix by checking HTTP responses for the header, and retesting with a scanner. Ensure core services continue to function as expected.
- Post-fix check: Use
curl -I https://example.comand verify that ‘X-Content-Type-Options: nosniff’ is present in the response headers. - Re-test: Re-run the scanner used earlier to confirm the vulnerability is no longer detected.
- Smoke test: Verify core website functionality, such as page loading and form submissions, still work correctly.
- Monitoring: Check web server logs for any errors related to header configuration changes.
curl -I https://example.com6. Preventive Measures and Monitoring
Update security baselines to include this setting, and add checks in your CI/CD pipeline to enforce it. Regular patch management is also important.
- Baselines: Update your server hardening baseline or CIS benchmark to require the ‘X-Content-Type-Options’ header.
- Pipelines: Integrate a static analysis tool (SAST) into your CI pipeline to check for missing security headers in web application code.
- Asset and patch process: Implement a regular review cycle for server configurations, at least quarterly.
7. Risks, Side Effects, and Roll Back
Incorrect configuration may cause unexpected website behaviour. Roll back by removing the added header from your web server’s configuration file.
- Risk or side effect 2: Server restart may cause brief service interruption.
- Roll back: Remove the line ‘Header always set X-Content-Type-Options “nosniff”‘ from your web server’s configuration file and restart the server.
8. References and Resources
- Vendor advisory or bulletin: Not applicable in this case, as it is a general configuration issue.
- NVD or CVE entry: Not applicable, as it’s a best practice rather than a specific vulnerability.
- Product or platform documentation relevant to the fix: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options