search

gimite / web-socket-js

HTML5 Web Socket implementation powered by Flash
BSD 3-Clause "New" or "Revised" License
2.73k stars 489 forks source link

Doesn't work if swf file loaded from remote server. #31

Closed lstoll closed 13 years ago

lstoll commented 14 years ago

If the SWF file is hosted on a different domain it doesn't work because scripts on the page aren't allowed to interact with it. This is the default security setting, however it makes less sense in this application as the relevant security settings would mainly be controlled by the web socket server.

A fix can be found at: http://github.com/lstoll/web-socket-js/commit/66a0a1ac9069eeb9e68e1ccbfc41ef8df1d366a4

imanel commented 14 years ago

I think it's worst approach you could take. First of all you don't want to allow this for all servers. Second - it should be served by server so admin can allow/deny specific hosts. That is why it is "security setting" in flash not just "annoying setting".

lstoll commented 14 years ago

What approach would you propose for something like http://gabbertalk.com, where we host the SWF file and provide a script (via socket.io) to embed a real-time chat in end users web pages - it's not possible to whitelist on a per domain basis in this case.

This security setting allows scripts on a page (and other SWF objects) to interact with a SWF file hosted on a remote server, which is kind of the point here. Normally this would be in place to prevent XSS-related items and trickery, however that isn't really a concern here - the component is intended to just act as a communications buffer. Even with the security settings in place, a "malicious" user could just download the swf, host it on their server, and do what they want. I don't think these settings are protecting us from anything, and are preventing convenient and websocket-compatible embedding.

Of course, I'm no flash expert so I'd love to here where this can be a security concern in this case, and proposals to handle this better.

Ref: http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/system/Security.html

gimite commented 14 years ago

I understand your situation and the best way I can think if for your situation is to apply your patch. Another solution is to distribute SWF file with the script to the users. Note that, with your patch, users can send anything to your WebSocket server, so you even cannot trust Origin header.

But I think it's not good idea to apply the patch in general, because it causes security issue for other typical situation, where you want to allow WebSocket connection only from your host, assuming a.com here. In this case you should write Flash socket policy file so that it allows only access from a.com. But if you allow cross-domain SWF, any hosts can access your WebSocket server via SWF file in a.com, which is not what you want.

Ideally it should have some configuration option to support both cases. One idea is to create another WebSocketMain.as applying your patch so that people can build it instead to allow cross-domain access.

rauchg commented 14 years ago

I agree with gimite, but I also recognize the need for this. I think what would be nice though is to ship web-socket-js with both files (WebSocket.swf and WebSocket_insecure.swf), and then let the user choose which one to use by setting WEB_SOCKET_SWF_LOCATION.

gimite commented 14 years ago

I guess people would likely just put both files in their server and just putting WebSocket_insecure.swf causes security issue :) So best thing I can think of is to let user compile insecure version when he needs. Please let me know if you have better idea.

rauchg commented 14 years ago

How about prefixing the name with .? Most web servers won't serve hidden files.

lstoll commented 14 years ago

What is the security issue of having the file on the server? Someone could just download the normal swf, put it on their server, and do what they like.

gimite commented 14 years ago

guille: Hmm I feel it's a bit dangerous to rely on it...

lstoll: The someone can put the SWF on their server, but not to your server (a.com). So it cannot connect to WebSocket server on your server, if you allow access only from a.com in Flash socket policy file.

lstoll commented 14 years ago

I see - so the flash policy is calculated on the server from which the swf file is retrieved from, not the page in which it is located?

I don't think it should be included pre-built - work around like the . are unreliable. Best to just include it as a seperate build file, or patch or something, and users who need this functionality can build it themselves.

gimite commented 14 years ago

TooTallNate suggested good idea to include the insecure version as ZIP file at http://github.com/gimite/web-socket-js/issues#issue/32 It looks safe enough. I'll do that soon.

gimite commented 14 years ago

Added ZIP file as TooTallNate suggested with: http://github.com/gimite/web-socket-js/commit/9e766377188d461f2046d951cc12645d457eb8e8 and added instruction to README file.

lstoll commented 14 years ago

The updated embedSWF call will probably be needed too.

gimite commented 14 years ago

It's already part of the change above.