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

Question

G'day:
I am reposting this from my blog ("ColdFusion 11: allowedextforinclude functionality has changed. But the docs haven't been") at the suggestion of Adobe support:
@dacCfml@ColdFusionCan you post your queries athttp://t.co/8UF4uCajTCfor all cfclient and mobile queries.— Anit Kumar Panda (@anitkumar85)April 29, 2014
This particular question is not regarding <cfclient>, hence posting it on the regular forum, not on the mobile-specific one as Anit suggested. I have edited this in places to remove language that will be deemed inappropriate by the censors here. Changes I have made are in [square brackets]. The forums software here has broken some of the styling, but so be it.
G'day:
Remember this one: "ColdFusion 11: preventing files from being included? [WTH], 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.
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:
<!---test.cfm---> <cfset message = "before"> <cfoutput> #message#<br> <cfinclude template="code.inc"> <cfset message = "after"> #message#<br> </cfoutput>
<!--- code.inc ---> <cfset message="within"> <cfoutput> #message#<br> </cfoutput>
And this all runs fine, as one would expect:
before
within
after
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">    <string>FOOBAR</string> </var>
And - having changed it back to something sensible: CFM, then the feature now "works":
before
#message#
after
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:
before<br> <cfset message="within"> <cfoutput> #message#<br> </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)...
Adam

Answer 1

Hi Adam,
Regarding "What if someone switches this on, and doesn't spot one of their old includes which has less-than-trivial CFML in it?", yeah I agree that'd be a problem.  Hmm, maybe both this.allowedextforinclude *and* this.compileextforinclude should've been supported (instead of replacing the former w/ the latter as was done)?  Example:
this.compileextforinclude="cfm,cfml,inc";
this.allowedextforinclude="cfm,cfml,inc,txt";
That way an exception could be thrown if cf|included file's extension wasn't in the this.allowedextforinclude list.
Perhaps the above could be shortened to:
this.compileextforinclude="cfm,cfml,inc";
this.allowedextforinclude="txt";//implicitly includes * from this.compileextforinclude (since -compile- implies -allowed-)
Dunno if that'd be confusing.
Anyhow, just some thoughts..
Thanks!,
-Aaron