Thursday 1 May 2014

ColdFusion 11: allowedextforinclude functionality has changed. But the docs haven't been

Remember this one: "ColdFusion 11: preventing files from being included? WTF, Adobe?". I can confirm this verymoderatelyslightly contentious feature has been changed in ColdFusion 11, but the docs have not been updated to reflect the change.

(Note: this functionality was changed to compileextforinclude, by the time ColdFusion 11 was actually released).

The issue is summarised thus (from the article linked-to above):

[...]out of the box ColdFusion 11 will only allow the inclusion of CFML and HTML files. Why? They cite "for security reasons". Here's a quote (posted in the bugtracker, originally from the pre-release forums):
"Vamseekrishna Manneboina: Yes, this was done as part of a security measure. You can now only include CFM/CFML files by default. You can specify additional extensions via a property called allowedextforinclude in neo-runtime.xml. By default, HTM and HTML file extensions are already added to this list/property, thereby allowing for inclusion of HTM and HTML files too by default."
OK, I disagree there's merit in this, some others agree, others disagree. But... so be it. I actually thought - if I was in a charitable mood - that the people that were "for" this change made a reasonable case for its inclusion, so - whilst not agreeing with them - I was content to just shrug and go "yeah, oh well".

Now this feature is still in the docs: "New in ColdFusion 11 - Restrictions", but this is not the way it now works. Initially I thought it had been removed completely (and I am now in the midst of retooling this article from saying that... as I only worked out what was going on 2/3rds of the way through writing it).

I did a secure install the other day, and one of the first things I tested was this:

<cfset message = "before">
<cfinclude template="">
<cfset message = "after">

<!--- --->
<cfset message="within">

And this all runs fine, as one would expect:


Next I checked neo-runtime.xml to see if the settings had been augmented to switch this off by default: but I'm buggered if I can see any reference to it anywhere.

So I then checked ColdFusion Administrator to see if there was any hint of it there, as this was one of the things Adobe said they were going to do in their solution to this. And there it is:

So by default now, anything is allowed. I figured I must have missed the setting in neo-runtime.xml, so changed the setting to "FOOBAR" so I could easily spot it, and there it is down @ /wddxPacket/data/array/*[16]/var[@name="compileextforinclude"] in neo-runtime.xml:

<var name="compileextforinclude">

And - having changed it back to something sensible: CFM, then the feature now "works":


However this is probably a worse security hole than the one they were trying to fix! It looks OK when looking at the render in the browser, but look at the actual raw mark-up:

<cfset message="within">
</cfoutput> after<br>

We have unparsed CFML source code sent to the browser. This is awful. What if someone switches this on, and doesn't spot one of their old includes which has less-than-trivial CFML in it? It's now publicly accessible. Adobe have created a feature which has the possibility to leak source code to the outside world. How is that a security feature?

Also interesting is that with the super-secure profile installed, this is still off by default? I would have thought it'd be on in this case?

I still don't think this feature has been implemented properly, and it all still points even more to the fact the Adobe ColdFusion bods don't really know what they're doing.

Anyway, I'll nudge Adobe to at least get the docs sorted out.

Time for work (3min ago)...