Response to comment (since redacted, it would seem) posted on the Adobe ColdFusion Blog

G'day:
I headed over to the Adobe ColdFusion Blog where there's an article on these security holes in ColdFusion (via web sockets) to reply to an update Awdhesh made yesterday. But the comment is gone. Well no it's not, here it is:

Hi Adam,
We have analyzed the issues as a whole and based on the concern you have raised.

Can you please detail which of these issues you are dealing with:
* web socket requests can access public methods: The issue is there and we are working on this on priority

* web socket requests can access non-web-browsable CFCs:A CFC can be accessed from outside of the webroot, based on the CF mapping only. It simply will not allow you to access any cfc if there is not mapping defined. Mapping is
a desirable behavior and a developer is very much aware what he is exposing. The mapping is being honored in case of AJAX Proxy as well. This AJAX proxy part is there form CF9 and we don’t see any issue out there. So based on our analysis,
there is no issue letting mapped CFC  get accessed.

* web socket requests do not trigger Application.cfc event handlers: This is not related to security as such and is not even an issue in general. But yes, it can be a nice enhancement which we can take up later.

* web socket requests error if a method have security roles specified: Even currently, this works the way you has described. If a CFC method is defined to be get accessed only under a specific role, it does the same. If accessed without proper security, the CFC invocation will throw proper exception if invoked via WebSocket.

Awdhesh
ColdFusion Team

This is exactly as posted, except I've de-emphasised the bits from my previous comment Awdhesh was replying to. There's a few things to address here.

To re-iterate, I have raised four issues with Adobe, and Awdhesh as responded to all of them in his comment. Cool. Well: cool he's responded, not so cool is what he says in places.

Here are the issues, a paraphrase of Adobe's position according to Awdhesh, and my feedback to that.

Web socket requests can access public methods

Awdhesh confirms this is the nub of the issue, and they're dealing with it. Excellent.

Web socket requests can access non-web-browsable CFCs

Awdhesh is under the misapprehension that CFCs mapped via a ColdFusion mapping ought to be web browsable, and this is actually by-design behaviour, and desirable.

No it ain't mate. This is my problem with the CF team sometimes... they're not actually web professionals (ie: they're enterprise Java application developers, and/or Java-based desktop application developers, but they aren't in the web industry, and their lack of experience in this area shows sometimes). Anyone who is a web professional knows that the only assets that should be web accessible are those that are available via the web site. IE: the thing that IIS or Apache (etc) manages. It is simply not ColdFusion's job to be serving files, or to decide what's externally accessible and what's not. Awdhesh is even "not getting" the difference between a CF mapping and a web server mapping. A CF mapping is something to avail the ColdFusion Server of assets. So like one can have assets outside CF's server directory, or simply to give a streamlined name to a sub-application (eg: given a CF root at /, then mapping /some/deep/path/here/ to /shortpath). This is nothing to do with a web server serving files. A virtual directory on the web server is the web-serving equivalent. If I want to expose CF files that are in a directory other than a sub-directory of the web site, then what I do is create a web server mapping, not a CF one.

If there are other mechanisms in CF that also allow external access to non-web-browsable files, then that's another security hole which needs patching. It sounds like the AJAX proxy has a similar security hole too. I shall check this at some stage soon.

Web socket requests do not trigger Application.cfc event handlers

Awdhesh correctly points out that this is not part of the security hole (although it could have been part of the fix for it, if it worked!), so they're deferring this. This being the case, Awdhesh, can you please make-public the issue I raised for this, so people can see it & possibly vote for it. TBH, you're positioning this like you think it's a feature request; it's not a feature request, it's a bug. Web socket requests should already be working this way. It's a bug that they don't.

Web socket requests error if a method have security roles specified

Awdhesh has missed the point here. These do not work. Whilst it's true that a user who is not in the specified role cannot access these methods (correct), a user who does have the correct role still can't. Not correct.

I hope Awdhesh's comment was taken down because it was a poor & misleading answer to my questions, so my commentary above is not necessary. But in case there's some other reason, then - Adobe guys - you've got a re-think coming your way.

I'd appreciate a follow-up to this (I'll cross-ref it on the ColdFusion Blog).

--
Adam