I have a web app that allows people exchange messages through websocket. I'm able to block most of connection requests that do not come from my website with this simple logic: var mydomain = 'http://www.mywebsite.com/'; if(url !== 'mydomain') { return; } Code (markup): However, I discovered that while that logic can block almost illegal requests it cannot block request from a file on a local computer say: file:///D:/test.html Code (markup): This allows easy access to my service and stealing my bandwidth for any purposes. I tried to block this request but it seems not working because doing something like below would throw: Uncaught SyntaxError: Illegal return statement var pathArray = window.location.pathname.split( '/' ); if(pathArray[1] === 'D:') { return; } Code (markup): How do I fix this and get it worked. (I want to disable some functions like XMLHttpRequest would not work on local computer's file.) Thank you,
You have completely misunderstood websockets. They are a client/server system, not a peer-to-peer system, meaning you need a server-side program that communicates with each user. JavaScript by itself cannot use websockets, unless you use Node (and even then, it still requires a server side).
I did use Node.js and that is just example. I've done something similar on server.js and it cannot block request from local file. The websocket server library I use is Einaros' ws here: https://github.com/einaros/ws
Unfortunately... well, welcome to the security risk of client side code. anyone who could figure out how to run it locally, can probably slap aside ANY scripting 'block's' you put in place because client side code is... well... client side. It HAS to be run on the client in the interpreter, meaning the client ALWAYS gets a copy of the source code, meaning security like you are thinking... Just plain doesn't EXIST. ANYTHING you add to the scripting to prevent it running locally can be slapped aside in seconds by anyone willing to bother. It's just the nature of the beast and why peer to peer in JS, or even using JS for security client to server is... well, a joke at best, a disaster at worst because again, JS is insecure by design and was never meant for making 'appplications' in the first place, it was meant to enhance a page's markup.
I agree with @deathshadow on most parts but the web is becoming more and focussed around front end applications designed in JavaScript now with frameworks like Angular.js. I think a solution to your problem is to build an array of allowed domains to access your script and then to check for that match by using indexOf. You don't need to return like that just make a condition around your codes logic to test this before running. As @deathshadow said, this wouldn't be difficult to overcome locally and you do need some server side validation in there to make this work 100%.
I think I found why did it happen: While this protocol is intended to be used by scripts in web pages, it can also be used directly by hosts. Such hosts are acting on their own behalf and can therefore send fake |Origin| header fields, misleading the server. Servers should therefore be careful about assuming that they are talking directly to scripts from known origins and must consider that they might be accessed in unexpected ways. In particular, a server should not trust that any input is valid.