1. Introduction
The Missing ‘Content-Type’ Header vulnerability occurs when a web server does not send a ‘Content-Type’ header with its responses. This allows clients to guess the data type, potentially leading to MIME sniffing attacks where malicious content is executed as if it were a different file type. It affects any web server or application that delivers files without specifying their content type. A successful attack could compromise confidentiality, integrity and availability of systems.
2. Technical Explanation
The root cause is the absence of the ‘Content-Type’ header in HTTP responses. An attacker can exploit this by sending a crafted file with an ambiguous extension or no extension at all. The client may then incorrectly interpret the file type, potentially executing malicious code embedded within it. This vulnerability is identified as CWE-693. For example, an attacker could send a JavaScript file without a ‘Content-Type’ header; some browsers might attempt to execute it as HTML if they cannot determine its type.
- Root cause: Absence of the Content-Type HTTP response header.
- Exploit mechanism: An attacker sends a file with no or ambiguous extension, relying on MIME sniffing by the client.
- Scope: All web servers and applications that serve files without specifying content types are affected.
3. Detection and Assessment
You can confirm if a system is vulnerable by checking HTTP responses for missing ‘Content-Type’ headers. A quick check involves using browser developer tools, while thorough assessment requires dedicated scanners.
- Quick checks: Use your browser’s developer tools (Network tab) to inspect the response headers of files served by the web server. Look for a missing ‘Content-Type’ header.
- Scanning: Burp Suite or OWASP ZAP can be configured to scan for missing Content-Type headers. These are examples only, and may require custom configuration.
- Logs and evidence: Web server access logs might show files being served without the header. However, this is not always reliable as log formats vary.
curl -I https://example.com/file.txt4. Solution / Remediation Steps
Configure your web server to include a ‘Content-Type’ header with the correct content type defined for each file served. This is a straightforward configuration change that significantly reduces risk.
4.1 Preparation
- Ensure you have access to modify the web server’s configuration files. A roll back plan is to restore the original configuration file.
- Change windows may be required for production systems; approval from a change advisory board may be necessary.
4.2 Implementation
- Step 1: Edit your web server’s main configuration file (e.g., httpd.conf, nginx.conf).
- Step 2: Add or modify the ‘Content-Type’ header for each file type served by the server.
- Step 3: Restart the web server to apply the changes.
4.3 Config or Code Example
Before
# Apache example - no Content-Type header defined
<FilesMatch ".(html|htm)$">
Options Indexes FollowSymLinks
After
# Apache example - Content-Type header added
<FilesMatch ".(html|htm)$">
Options Indexes FollowSymLinks
Header set Content-Type "text/html"
4.4 Security Practices Relevant to This Vulnerability
Secure configuration is the most relevant practice for this vulnerability. Input validation can also help prevent malicious files from being served in the first place.
- Practice 1: Secure Configuration – Regularly review and harden web server configurations, ensuring all necessary security headers are present.
- Practice 2: Safe Defaults – Configure your web server with secure defaults that include essential security features like Content-Type header enforcement.
4.5 Automation (Optional)
# Ansible example - add Content-Type header for HTML files
- name: Add Content-Type header for HTML files (Apache)
lineinfile:
path: /etc/httpd/conf/httpd.conf
regexp: '^<FilesMatch ".(html|htm)$">'
insertafter: '^Options Indexes FollowSymLinks'
line: 'Header set Content-Type "text/html"'5. Verification / Validation
Confirm the fix by checking HTTP responses again for the presence of ‘Content-Type’ headers. A negative test involves attempting to upload a file without an extension and verifying it is not executed as unexpected content type.
- Post-fix check: Use `curl -I https://example.com/file.txt` and verify that the output includes a ‘Content-Type’ header (e.g., Content-Type: text/plain).
- Re-test: Repeat the quick check from Section 3, confirming that all files now have a ‘Content-Type’ header.
- Monitoring: Check web server logs for any errors related to Content-Type headers. This is an example only; log formats vary.
curl -I https://example.com/file.txt6. Preventive Measures and Monitoring
- Baselines: Update your web server security baseline to include the requirement for ‘Content-Type’ header enforcement.
- Pipelines: Add checks in your CI/CD pipeline to validate that all files served by the web server have a valid ‘Content-Type’ header.
- Asset and patch process: Implement a regular patch review cycle (e.g., monthly) to ensure timely updates to address known vulnerabilities.
7. Risks, Side Effects, and Roll Back
Incorrectly configured Content-Type headers can cause files to be rendered incorrectly or not at all. A roll back involves restoring the original web server configuration file.
- Roll back: Restore the original web server configuration file from your backup. Restart the web server.
8. References and Resources
- Vendor advisory or bulletin: N/A
- NVD or CVE entry: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type
- Product or platform documentation relevant to the fix: https://www.iana.org/assignments/media-types/media-types.