Feature #43484
open
Detect attachment content type from file contents instead of trusting client-provided values
Description
Redmine currently stores the content type of uploaded files based on the value provided by the client, such as web browsers and API clients. This approach is not reliable and can lead to incorrect or misleading MIME types, especially when the client declares a spoofed or incorrect type.
According to the OWASP File Upload Cheat Sheet, the Content-Type header for uploaded files cannot be trusted, because it is easy to spoof.
The attached patch changes the behavior so that Redmine no longer trusts the client-provided content type. Instead, it detects the content type by inspecting the actual file contents using Marcel.
Files
Related issues
Updated by Go MAEDA 9 months ago
- Related to Feature #43473: Reject file uploads when actual MIME type does not match the file extension added
Updated by Go MAEDA 6 months ago
- File 0001-Improve-Redmine-MockFile-to-better-mimic-File-behavi.patch 0001-Improve-Redmine-MockFile-to-better-mimic-File-behavi.patch added
- File 0002-Stop-using-legacy-image-x-ms-bmp-MIME-type-for-BMP-f.patch 0002-Stop-using-legacy-image-x-ms-bmp-MIME-type-for-BMP-f.patch added
- File 0003-Stop-using-legacy-application-x-pkcs7-signature-MIME.patch 0003-Stop-using-legacy-application-x-pkcs7-signature-MIME.patch added
- File 0004-Detect-attachment-content-type-from-file-contents-in.patch 0004-Detect-attachment-content-type-from-file-contents-in.patch added
- File deleted (
0001-Improve-Redmine-MockFile-to-better-mimic-File-behavi.patch) - Target version set to Candidate for next major release
- File deleted (
0002-Stop-using-legacy-image-x-ms-bmp-MIME-type-for-BMP-f.patch) - File deleted (
0003-Stop-using-legacy-application-x-pkcs7-signature-MIME.patch) - File deleted (
0004-Detect-attachment-content-type-from-file-contents-in.patch)
I have updated the patches. Rebased for the current trunk and made minor changes.
Updated by Marius BĂLTEANU about 2 months ago
- Target version changed from 7.0.0 to 7.1.0
Updated by Go MAEDA 12 days ago
- File 0001-Improve-Redmine-MockFile-to-better-mimic-File-behavi.patch 0001-Improve-Redmine-MockFile-to-better-mimic-File-behavi.patch added
- File 0002-Stop-using-legacy-image-x-ms-bmp-MIME-type-for-BMP-f.patch 0002-Stop-using-legacy-image-x-ms-bmp-MIME-type-for-BMP-f.patch added
- File 0003-Stop-using-legacy-application-x-pkcs7-signature-MIME.patch 0003-Stop-using-legacy-application-x-pkcs7-signature-MIME.patch added
- File 0004-Show-the-same-file-type-icon-whether-the-content-typ.patch 0004-Show-the-same-file-type-icon-whether-the-content-typ.patch added
- File 0005-Detect-attachment-content-type-from-file-contents-in.patch 0005-Detect-attachment-content-type-from-file-contents-in.patch added
- File 0006-Send-an-attachment-inline-based-on-its-detected-cont.patch 0006-Send-an-attachment-inline-based-on-its-detected-cont.patch added
Updated the patches.
Two problems became visible once the content type is detected from the file contents, and each is fixed in its own commit.
Attachment icons:
Marcel does not always spell a type the way Redmine::MimeType spells the type of the same kind of file. For example, Marcel returns text/javascript where Redmine::MimeType returns application/javascript. The icon name was derived from the content type, so files like this lost their icon and fell back to the generic one. The icon is now looked up in a table that lists every spelling.
Inline display:
Content-Disposition was decided from the file extension while Content-Type was decided from the detected content type, so the two could disagree. An HTML file named foo.pdf was sent as text/html with Content-Disposition: inline. Both are now decided from the same value.
Other fixes:
- The content type is re-detected on every rename path. Previously only attaching by token did this, so renaming from the attachment edit screen or through the REST API left a stale content type.
- Renaming no longer raises an error when the file is missing from disk.