Web Server Misconfiguration: Insecure Content-Type Setting

Failure to correctly enforce the content-type could allow an attacker to conduct Cross-Site Scripting or information theft attacks.

Failure to specify a Content-Type header in the HTTP Response could expose the application to Cross-Site Scripting vulnerabilities via:

Content Sniffing Mismatch:
Failure to explicitly specify the type of the content served by the requested resource can allow attackers to conduct Cross-Site Scripting attacks by exploiting the inconsistencies in content sniffing techniques employed by the browsers.
The Content-Type header is used by:
- The web server to dictate how the requested resource is interpreted by the user agent. In the absence of this header the browser depends on content sniffing algorithms to guess the type of content and render or interpret it accordingly.
- File upload filters to discard file types not allowed by the application. In the absence of a Content-Type header, the file upload filter relies on the file extension or the content of the file to detect and store an appropriate mime type for the uploaded file.
The lack of explicit content type specification can allow attackers to exploit the mismatch between the mime sniffing algorithm used by the browser and upload filter. By uploading files with benign extensions (like .jpg), an attacker can easily bypass the upload filter to upload files containing malicious HTML content. The browser's content sniffing algorithm will however render it as HTML based on the content of the file thus executing any malicious scripts embedded within the HTML content.

Character Set Mismatch:
Character set specification is part of the Content-Type header. Absence of this specification could allow attackers to bypass input validation filters or HTML entity escape functionality and conduct Cross-Site Scripting attacks against the target application. When the character set is not specified, browsers will attempt to guess the most appropriate character set. This could result in a mismatch between the character set assumed by the application during the generation of the content and by the browser during the parsing and interpretation of the same content. An attacker can exploit this inconsistency to encode attacks using a character set that'll hide the malicious payloads from the validation filters and escaping mechanisms put in place by the application but at the same time will be interpreted by the browser as a valid executable entity.

Below example scenarios demonstrate the exploitation of the weakness:

Content Sniffing Mismatch:

1. Attacker uploads a file with .jpg extension and no Content-Type specification. The file contains malicious HTML and JavaScript content embedded inside.
2. In the absence of the Content-Type header, the application saves the uploaded file along with the mime type of the .jpg
3. The attacker uses social engineering to entice the desired target into accessing the uploaded file
4. Upon receiving the requested file without the Content-Type header, the target's browser assumes the content type to be HTML based on the HTML and JavaScript content inside and renders the file causing attacker's JavaScript payload to be executed.

Character Set Mismatch:
1. Attacker converts the desired payload of <script>alert(document.location)</script> into UTF-7 encoded string +ADw-script+AD4-alert(document.location)+ADw-/script+AD4 and sends it to the vulnerable application.
2. An application using the ISO-8859-1 character set for filtering or escaping special characters will fail to detect the the '<' and '>' characters as dangerous
3. The absence of character set specification due to the missing Content-Type header will force the browser to guess the character set to use for rendering the application response containing the attacker's payload. If the browser correctly guesses the encoding as UTF-7, the injected payload will be successfully executed.

Programmers can use HTTP response headers to enforce content-type policies and prevent browsers from insecurely interpreting malicious JavaScript content sent by attackers with a misleading mime type specification. Web server misconfiguration can cause an application to send HTTP responses with missing Content-Type header or specify a mime type that does not match up accurately with the response content. When a browser receives such a response, it attempts to programmatically determine the mime type based on the content returned in the response. The mime type derived by the browser, however, might not accurately match the one intended by the application developer. Such inconsistencies have historically allowed attackers to conduct Cross-Site Scripting or data theft using Cascading Style Sheets (CSS) by letting them bypass server-side filters using mime type checking and yet have the malicious payload with a misleading mime type specification executed on the client-side due to inconsistent browser mime sniffing policies.
In addition to safe mime handling policies for CSS parsing, developers can also dictate the browser's mime sniffing behavior. By configuring the web server to include the X-Content-Type-Options: nosniff header in all HTTP responses, developers could avoid incorrect interpretation of the responses even in the absence of accurate Content-Type specification.
Adherence to this secure configuration practice is highly recommended. Developers and administrators must, however, take into account that the protection is restricted to IE versions 9 and above and it will not protect users relying on older versions of IE. To protect these users, it is important that additional safeguards are implemented to complement this protection mechanism.