Coldfusion site can't be reached after changing fileExtensions allowUnlisted="false" in IIS 10.0

[BILL314613570ssy]

Hi,

I am having issues with connecting to my ColdFusion website after changing  fileExtensions allowUnlisted="false" in IIS 10.0.
   If I change allowUnlisted back to true, then the website works perfectly. Neither the IIS logs nor the ColdFusion logs show offer any assistance in debugging this problem.  There is a proxy if that matters.

My web.config is shown below. (I have tried without the mimeMap settings and I have tried resetting the IIS connector)

Any assistance would be greatly appreciated! Thanks!

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="false" allowHighBitCharacters="false">
<fileExtensions allowUnlisted="false">
<add fileExtension=".cfm" allowed="true" />
<add fileExtension=".cfc" allowed="true" />
<add fileExtension=".json" allowed="true" />
<add fileExtension=".htm" allowed="true" />
<add fileExtension=".css" allowed="true" />
<add fileExtension=".html" allowed="true" />
</fileExtensions>
<verbs allowUnlisted="true" />
</requestFiltering>
</security>
<staticContent>
<mimeMap fileExtension=".cfm" mimeType="text/html" />
<mimeMap fileExtension=".cfc" mimeType="text/html" />
</staticContent>
</system.webServer>
</configuration>

[Charlie Arehart · Accepted solution]

Bill, the "simple" answer is to add ".dll" as another allowed extension (if you're going to go this route of reversing this "file name extensions" list --in IIS's request filtering feature--from its default of being a blacklist to instead being a whitelist).

The reason this is needed (when you do that) is not at all obvious: as you may know, when you setup a connection between IIS (or Apache) using the CF "web server configuration tool" (wsconfig), it actually sets up a Tomcat connector (which Adobe has modified slightly for their reasons). And that Tomcat connector works in a way that many would not expect: when you request a file that it handles (like a .cfm file), it actually causes a request also to the isapi_redirect.dll as well (which the jakarta virtual directory points to).  One can see this in tools like the IIS "failed request tracing" tool, though it sometimes presents itself in other ways, such as when the dll shows up in IIS logs instead of the cfm page request (as covered in this Tomcat doc on that and more about this isapi_redirect.dll setup--all of which Adobe handles for us with the connector tool.)

Again, this is not an Adobe "bug" or "mistake" but just an inheritance we receive by way of Adobe's use of that Tomcat IIS connector. 

I've tried in the past to find some way to tweak things further so as to not allow any OTHER requests for dll's (for folks wanting to setup a whitelist this way). Sadly, the IIS request filtering feature (which you are manipulating here) doesn't seem to offer that flexibility. I'd welcome any ideas or discoveries anyone has. Some good news is that CF sites don't have any reason to offer dll files themselves--but it's true that if someone slipped one in it could become accessible by this change.

And if it's any consolation, in the default IIS blacklist extension list (where IIS comes with a list of a couple dozen predefined blocked extensions) does NOT block .dll extensions by default...so everyone who just uses IIS to connect to CF has always had dll's unblocked, for better or worse. 🙂 Again, this issue only arises when someone tries to change that feature to be a whitelist instead, as you have here.

At least now it should make a bit more sense, what's going on for you. Hope that helps.

[BILL314613570ssy]

Charlie,

Thanks so much! that did the trick! 🙂 I really appreciate the help!

[Charlie Arehart]

Great to hear and glad to have helped. It could help if you'd mark my first reply as an "answer". Thx. 

[BILL314613570ssy]

done! 🙂

[Charlie Arehart]

Thanks for that, Bill. And I'll add one more thing: the CF lockdown guide (created for Adobe by Pete Freitag) does in fact cover this matter of enabling the .dll extension, when whitelisting extensions. It's in section 5.7.3 (of the 2023 guide), where he proposes that more specifically you need only allow the .dll extension in the jakarta virtual directory. That of course helps limit the exposure, versus doing it at the site level.

Note he even goes on to disucss how you could even add protection to ensure that ONLY that dll is called within that folder. Pete's awesome! 

While it may seem a bit fiddly, if you're going to go the whitelist approach, you may as well take that extra step to get the protection you sought. And while he shows it only in words (and presumes use of the UI), you can definitely do it also via a web.config file if you prefer.