Example: Point-to-Point communication

[community_help]

This question was posted in response to the following article: http://help.adobe.com/en_US/ColdFusion/10.0/Developing/WSe61e35da8d318518767eb3aa135858633ee-7fed.ht...

[henrylearn2rock]

CF10 websocket p2p can invoke any public functions in any CFC from JavaScript. How is this Not a security risk?

http://stackoverflow.com/questions/17351214/cf10-websocket-p2p-can-invoke-any-public-functions-in-any-cfc-from-javascript-h

[Anit_Kumar]

Hello henrylearn2rock,

We are aware about the vulnerability using the websockets and the Adobe's Security team is working towards the fix. Here is the link to the blog post.

http://blogs.coldfusion.com/post.cfm/coldfusion-10-websocket-vulnerebility

Regards,

Anit Kumar

[BKBK]

My reaction in Stackoverflow:

"It is certainly not a security risk for Javascript, or any other client for that matter, to be able to invoke any public method on any CFC. That is the expected behaviour for interfaces that you choose to expose as public. To solve this, the ColdFusion Team has to return to their original design of Websocket and redo it."

[Adam Cameron.]

My reaction to your reaction:

"public" is not the same as "remote". You seem to be getting confused about this. PUBLIC methods should not be web-accessible. Only REMOTE ones should be. Reading: http://help.adobe.com/en_US/ColdFusion/10.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7f5c.html

--

Adam

[BKBK]

I am not confused at all. In fact, what you say fits the picture I have painted, namely, the following.

When you expose an interface as Public, then expect, well, public access. That is so by design. It is not a security risk! If you insist on calling it a risk then, according to your design, it is a risk you are willing to take.

As I said, "To solve this, the ColdFusion Team has to return to their original design of Websocket and redo it". They might choose to make access Remote. That is a possible solution. There are others.

[Adam Cameron.]

I am not confused at all. In fact, what you say fits the picture I have painted, namely, the following.

When you expose an interface as Public, then expect, well, public access[etc]

Like I said: you're confused: you are misunderstanding the meaning of "public" in the context of CFC method access levels. "Public" does NOT mean "public access".

Read the docs I pointed you at.

--

Adam

[BKBK]

Adam Cameron. wrote:

Like I said: you're confused: you are misunderstanding the meaning of "public" in the context of CFC method access levels. "Public" does NOT mean "public access".

Read the docs I pointed you at.

I read the your reference. I was already familiar with the stuff. You are the one who seems to be confused, mate. It requires a little leap in interpretation.

The original poster said, "CF10 websocket p2p can invoke any public functions in any CFC from JavaScript". So he uses "public" as an adjective. You yourself wrote, "PUBLIC methods should not be web-accessible.". So, you, too, use "public" as an adjective.

The context is implicitly clear. Public, not as in general public, but public, as opposed to private, package, etc. Incidentally, whereas you, two, talk about functions and methods, I talk about interfaces. That is in keeping with the theme I focussed upon, design.

[henrylearn2rock]

Examples should be updated. Every cffunctions in mycfc.cfc should have access="remote".