tracker issue : CF-4203258

select a category, or use search below
(searches all categories and all time range)

cffile action=upload should allow file extensions when strict is true

| View in Tracker

Status/Resolution/Reason: To Test//NeedMoreInfo

Reporter/Name(from Bugbase): Peter Freitag / ()

Created: 08/09/2018

Components: Tags

Versions: 13.0

Failure Type: Incorrect w/Workaround

Found In Build/Fixed In Build: 2018.0.0.310739 /

Priority/Frequency: Normal / Some users will encounter

Locale/System: ALL / Platforms All

Vote Count: 1

Problem Description: Using file extensions is actually a better than MIME type checking, however if you specify a list of file extensions in the accept attribute, then you must set strict="false" otherwise you get an exception:

When the value of the attribute STRICT is TRUE, it requires valid MIME types in the attribute(s): ACCEPT.

Steps to Reproduce: Create a page with: <cffile action="upload" accept=".pdf" formfield="file">

Actual Result: Throws exception "When the value of the attribute STRICT is TRUE, it requires valid MIME types in the attribute(s): ACCEPT." Note this is not new for CF2018, it goes back to CF10 initial release.

Expected Result: It should allow file extensions when strict=true. Ideally you could introduce a new attribute then we could do this: <cffile action="upload" strict="true" accept="application/pdf" extensions=".pdf" formfield="file"> then it could check BOTH the mime type and file extensions.

Any Workarounds: You have to explicitly set strict="false" when using a file extensions in accept attribute, eg  <cffile action="upload" accept=".pdf" formfield="file" strict="false">



I see this is marked "Need More Info" - what other info do you need?
Comment by Peter F.
30263 | February 15, 2019 08:13:27 PM GMT
Amen to this.
Vote by Charlie A.
30265 | February 15, 2019 09:51:38 PM GMT
Pete asks a great question. I thought the same as I saw that. I'll add more: you only get the error Pete mentioned (when strict is true) if you do NOT add any mimetypes to the ACCEPT. If you DO add mimetypes AND also add extensions, they are simply ignored! Unless you switch to strict false, when of course then you lose the checking of the file content. This is madness! So yes, either allow checking of both mime types AND extensions (whether strict is true or false), or if you must, then add a new attribute to list acceptable extensions! I had a client come to me who had been hacked because of all this: bad guys had uploaded a cfm file (to a page doing cffile action="upload") with content that looked like an image (at the top) but had CFML at the bottom. It passed the strict test ("looked like a png"), but then that file was executable. And as the DESTINATION attribute was set to a web-acccessible folder, now that was executable. Yes, I told them that they should have been more careful about allowing uploads to a web-accessible folder. But they thought the strict would have caught that a file that "looked like an image" but had script in it. If it doesn't, it almost begs what strict is doing. I gather it's only looking at the top of the file to determine if it looks like one of the valid ACCEPT mime types. That's definitely NOT enough. If we DO specify extensions (in ACCEPT), then it ought to fail if the extension of the uploaded file doesn't match the list (whether strict is true or not). BTW, in the CFML Ref on cffile action="upload", the first sentence about strict implies this extensions WOULD be allowed for either true or false. The second and third sentences contradict that.
Comment by Charlie A.
30264 | February 15, 2019 10:00:47 PM GMT
Better still, one might argue that the CF Admin should define a list of extensions that would be allowed or blocked for upload, by default. That could be overridden at the app or code level. Of course, a whitelist is generally better than a blacklist, but I know either takes some thought for Adobe to setup correctly. Of course, I welcome correction on commentary on my two comments here. I know this stuff is challenging.
Comment by Charlie A.
30272 | February 16, 2019 12:48:28 AM GMT