Security improvement: Validate content-type of uploaded files

Created on 19 November 2016, over 8 years ago
Updated 23 March 2025, 14 days ago

Drupal prevents executable files (Flash files, for instance) with a benign extension (jpg, etc.) from being invoked by setting the X-Content-Type-Options header to nosniff. The "nosniff" header is a good barrier but a content-type check should be performed on any given file before storing it on the server, because in the potential case that a Drupal administrator adds a different ‘.htaccess’ file, removes it or modifies the content provided by default, this issue can be exploited through any upload form located in the latest version of Drupal.

To reproduce, first disabled the setting of X-Content-Type-Options. Then take a basic Flash movie, rename it with a .jpeg extension, and upload it to the Drupal site. Then invoke the file (which can be executed as Flash content if loaded from an ‘object’ tag) from a remote site. As there is no cross-domain policy file by default to prevent Flash content accessing sensitive locations, this can lead a person to perform unauthorized requests.

For increased security, In addition to the setting of X-Content-Type-Options header to nosniff, the content-type should be checked on upload. There are some uploaders with mime-type validation and we suggest that Drupal may include this features in future releases. A good example of this, is an PHP uploader library that performs several mime-type checks over the file, including the mentioned one: https://github.com/samayo/bulletproof.

In addition, the X-Content-Type-Options header should be added to web.config.

Applies to 8.x and 7.x.

Reported by desarrollo_incibe.
Reproduced by David_Rothstein.

🐛 Bug report
Status

Postponed

Version

11.0 🔥

Component

file system

Created by

🇺🇸United States micnap

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024