| Name |
XSS Using MIME Type Mismatch |
|
| Likelyhood of attack |
Typical severity |
| Medium |
Medium |
|
| Summary |
An adversary creates a file with scripting content but where the specified MIME type of the file is such that scripting is not expected. The adversary tricks the victim into accessing a URL that responds with the script file. Some browsers will detect that the specified MIME type of the file does not match the actual type of its content and will automatically switch to using an interpreter for the real content type. If the browser does not invoke script filters before doing this, the adversary's script may run on the target unsanitized, possibly revealing the victim's cookies or executing arbitrary script in their browser. |
| Prerequisites |
The victim must follow a crafted link that references a scripting file that is mis-typed as a non-executable file. The victim's browser must detect the true type of a mis-labeled scripting file and invoke the appropriate script interpreter without first performing filtering on the content. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Explore |
The adversary identifies a webpage that allows uploading content through an HTTP POST request. This is typically a blog or forum where other users will access the uploaded content. |
|
| 2 |
Experiment |
The adversary creates a file with scripting content that they wish to be executed on other users' web browsers. This file is then uploaded through a POST request and the MIME type is specified as a file type that cannot execute scripting content, such as text/plain. |
|
| 3 |
Experiment |
The adversary then attempts to access the uploaded content to see if the browser correctly executes their desired scripting content |
|
| 4 |
Exploit |
Once the adversary has determined that their uploaded script will run when accessed, they either wait for users to access the content on their own or they target users to access their content through phishing emails. |
|
| 5 |
Exploit |
The adversary's script can do just about anything, but a common use is to read a user's cookies which may contain a token. This can then be used to launch a Cross Site Request Forgery Attack. |
|
|
| Solutions | |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-20 |
Improper Input Validation |
| CWE-79 |
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') |
| CWE-646 |
Reliance on File Name or Extension of Externally-Supplied File |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-592 |
This type of attack is a form of Cross-site Scripting (XSS) where a malicious script is persistenly "stored" within the data storage of a vulnerable web application. Initially presented by an adversary to the vulnerable web application, the malicious script is incorrectly considered valid input and is not properly encoded by the web application. A victim is then convinced to use the web application in a way that creates a response that includes the malicious script. This response is subsequently sent to the victim and the malicious script is executed by the victim's browser. To launch a successful Stored XSS attack, an adversary looks for places where stored input data is used in the generation of a response. This often involves elements that are not expected to host scripts such as image tags (<img>), or the addition of event attibutes such as onload and onmouseover. These elements are often not subject to the same input validation, output encoding, and other content filtering and checking routines. |
|