Content
View differences
Updated by Niels Lindenthal almost 12 years ago
Reproduce:
- Create HTML file with JavaScript
- Set up mitmproxy or other mechanism to capture, edit and replay HTTP requests
- Create work package, submit
- Click update, attach HTML file, submit
- Edit last POST request with mitmproxy: edit body
- change Content-Type from <code>text/html</code> to <code>application/unknown</code>
- increase lock\_version by 1
- Replay request
- Open work package in browser (Chrome or IE), click uploaded file
Expected: File is only offered as download and not opened in browser
Result: HTML file is displayed and JavaScript is executed, which can lead to XSS
This gave me the idea to use the application/unkown content type and provides some things we could do: http://security.stackexchange.com/questions/7506/using-file-extension-and-mime-type-as-output-by-file-i-b-combination-to-dete/7531
Some more info: https://security.stackexchange.com/questions/12896/does-x-content-type-options-really-prevent-content-sniffing-attacks
Sample work package: https://openproject-org.qa.finn.de/work\_packages/3933
## Previous descriptions
### v2 about setting content type header
Content type handling for user provided content has the following issues:
1. we trust the user provided content type (see original message),
2. we don’t prevent the browser from sniffing the content type of the served content (see iX 04/2014 - *In sicheren Bahnen* page 60ff).
This allows users to upload potentially malicious content **<span class="1"></span>** that a browser may executes **<span class="2"></span>** (for instance a malicious html page that gets executed on IE).
### v1 about not trusting user-provided content types
Currently, we trust the user for the provided Content-Type and just use it for the download.
I don’t see an immediate attack vector in this, but it can’t be good letting a user specify an arbitrary MIME type. We might just verify the content type is in a list of known types, otherwise we guess it.
- Create HTML file with JavaScript
- Set up mitmproxy or other mechanism to capture, edit and replay HTTP requests
- Create work package, submit
- Click update, attach HTML file, submit
- Edit last POST request with mitmproxy: edit body
- change Content-Type from <code>text/html</code> to <code>application/unknown</code>
- increase lock\_version by 1
- Replay request
- Open work package in browser (Chrome or IE), click uploaded file
Expected: File is only offered as download and not opened in browser
Result: HTML file is displayed and JavaScript is executed, which can lead to XSS
This gave me the idea to use the application/unkown content type and provides some things we could do: http://security.stackexchange.com/questions/7506/using-file-extension-and-mime-type-as-output-by-file-i-b-combination-to-dete/7531
Some more info: https://security.stackexchange.com/questions/12896/does-x-content-type-options-really-prevent-content-sniffing-attacks
Sample work package: https://openproject-org.qa.finn.de/work\_packages/3933
## Previous descriptions
### v2 about setting content type header
Content type handling for user provided content has the following issues:
1. we trust the user provided content type (see original message),
2. we don’t prevent the browser from sniffing the content type of the served content (see iX 04/2014 - *In sicheren Bahnen* page 60ff).
This allows users to upload potentially malicious content **<span class="1"></span>** that a browser may executes **<span class="2"></span>** (for instance a malicious html page that gets executed on IE).
### v1 about not trusting user-provided content types
Currently, we trust the user for the provided Content-Type and just use it for the download.
I don’t see an immediate attack vector in this, but it can’t be good letting a user specify an arbitrary MIME type. We might just verify the content type is in a list of known types, otherwise we guess it.