Note: This blog post is from 2016. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
As folks continue to explore ColdFusion (2016 Release), aka CF2016, regarding what's new or changed, I thought I'd put together a listing of what has changed in the CF Admin specifically. This is another in a
series of posts I started last week on CF2016.
[....Continue Reading....]
1. SSL
2. Our admins would rather hit that in the browser from their desk without RDP. And none of these servers are accessible via the ports we are using for SSL (non-standard).
One other caveat to this. For all the interlinking to work (images, cfcs, etc) you will also need a virtual directory in your site /CFIDE - otherwise things will not work. So, 2 virtual directories.
/whateveryyourcfadminwillbecalled
/CFIDE - lots of references to /cfide/.....in the code
One note, Our CFAdmins are set up on their own websites over non-standard SSL Ports with a certificate. So, it's not the wild west!
I know you're presumption is that "still locking down the CFIDE/administrator" directory would not seem "necessary", because you don't see CF adding a CFIDE virtual directory to the web server.
But that doesn't matter. Check it out. You will find that you CAN still get to the CF Admin, even though you see "no CFIDE virtual directory" in your web server.
This is because of a long-existing and little-known but potentially troublesome "feature" in CF: if you request a file (or folder and file) in your web server that is "not found" as per the web server configuration, CF will STILL look for that file/folder in the CF instance's wwwroot.
Now, if you use the CF Admin feature (in 11 and above) to tell CF (in the Security>Allowed IP addresses page, at the bottom of that page) to only allow certain IP addresses to access to the Admin (and RDS and other secured features), that would at least limit your exposure.
And you could certainly ADD a CFIDE virtual directory yourself to your web server, and then lock things down in additional ways, such as requiring extra security/logins, etc.
So just be VERY careful about exposing the CFIDE via your web server, as I alluded to in the post. Again, I only mentioned it for those who really pressed to know the implications. Yours is another useful one to now discuss.
In fact, it may be worth noting that for RDS, what you REALLY need to secure especially is the URL /CFIDE/main/ide.cfm. That's what RDS uses: and no, there's never been a main folder or an ide.cfm file, but instead that is done as a filter, as defined in CF's \wwwroot\WEB-INF\web.xml file (nothing new or different about this in 2016, as it's been like this since CF6).
So if you do "open" that block in the uriworkermap.properties, it will still be protected if either you use the CF Admin security feature to block access to such things by IP address, or if you create a virtual directory called CFIDE and lock that down.
But really: people should be VERY VERY cautious about doing anything that exposes their CFIDE or ESPECIALLY the RDS feature on the web. Adobe is trying with these changes in CF2016 to PROTECT you from vulnerabilities related to that.
Undoing those "locks" is as risky as living in a house with locks on the doors and choosing to unlock them. You may not "think" you "live in a bad neighborhood", to stretch the analogy, but unlike a real home, web servers are under CONSTANT attack from people trying to find any way to get in. (Picture those "sentinels" in the Matrix movies, or the spider robots in Minority Report. Attackers are THAT perniciously persistent, so you don't want to give them even a crack in the door.)
But after it was reinstalled, white screen, no cfadmn except via 8500
It also seems to be a bit half-arsed, as there are still things that are still set to use the CFIDE folder by default, such as the missing template handlers, which are obviously no longer going to work is CFIDE is blocked.
As for your feeling that it "did work in the past" for you, you either were looking at CF11 or had by some combination of customizations gotten it to work. (See my last comment above, about how it's possible, but not generally recommended.)
As for your feeling that there would be a problem with the site-wide error handler, nope, there is none. That file (/CFIDE/administrator/templates/secure_profile_error.cfm, when enabled as the site-wide error handler as it is by default with the "secure profile" feature) is NOT served via IIS (or Apache or nginx). It's called from within CF, just like some other things that leverage CF Admin mappings. So the "block" in IIS has no impact on it.
You can confirm it yourself. Enable that sitewide error handler, and visit a page generating an error. Regardless of whether you visit the URL via CF's built-in web server or an external web server (like IIS), you will see the "blue ball" error page of the CF secure error handler.
If you still have some other aspect that you think is "wrong" about the approach, do share your thoughts. We should all be always learning.
I am a bit confused about how the "Session storage in Redis" really works. Since we cannot use J2EE session, which means that we need to use ColdFusion session and with that we will need to pass the CFID and CFToken in the URL's, right? Wont that be a security risk?
But no, you do not "need to pass the CFID and CFToken in the URL'" when you use CF sessions instead of J2EE sessions. The need to pass tokens in the URL is only for when the browser doesn't support cookies. And if you use J2EE sessions, you would then STILL need to pass a token in the URL, but it would be the jsessionid instead.
So yep, one difference between CF and J2EE sessions is the kind of token (though not whether it needs to be passed in the URL, as both do, if needing to support browsers that don't support cookies, which is rare these days).
But the more important difference that most complain about, in being "forced" to use CF sessions to leverage that Redis sessions feature (also set on the CF admin "memory variables" page), is that the cookies underlying J2EE sessions are more secure in many ways.
That can be addressed, though, in a way that it seems few realize. I hope to do a blog post (even perhaps today) to explain that. I think then that most people WOULD more readily be willing and able to consider leveraging things like the Redis sessions feature, which Adobe (curiously) set to work ONLY with those CF sessions (and not J2EE sessions).
If and when I DO post that blog entry (hopefully today), I will try to remember to come back and share that link here.
But you say you are "confused" how the Redis session feature "really works". If you're asking about something else (than this requirement to use CF sessions and not J2EE ones), do share what is confusing. (Then again, that's going beyond the real focus of this post. At some point, I want to do a new blog post on the Redis sessions itself, but until then, you can ask here.)