Why this return statement illegal

Discussion in 'JavaScript' started by ketting00, May 29, 2014.

  1. #1
    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,
     
    Last edited: May 29, 2014
    ketting00, May 29, 2014 IP
  2. xtmx

    xtmx Active Member

    Messages:
    359
    Likes Received:
    12
    Best Answers:
    4
    Trophy Points:
    88
    #2
    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).
     
    xtmx, May 29, 2014 IP
  3. ketting00

    ketting00 Well-Known Member

    Messages:
    782
    Likes Received:
    28
    Best Answers:
    3
    Trophy Points:
    128
    #3
    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
     
    Last edited: May 30, 2014
    ketting00, May 29, 2014 IP
  4. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,999
    Best Answers:
    253
    Trophy Points:
    515
    #4
    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.
     
    deathshadow, May 30, 2014 IP
    HuggyStudios likes this.
  5. HuggyStudios

    HuggyStudios Well-Known Member

    Messages:
    724
    Likes Received:
    20
    Best Answers:
    26
    Trophy Points:
    165
    #5
    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%.
     
    HuggyStudios, May 31, 2014 IP
  6. ketting00

    ketting00 Well-Known Member

    Messages:
    782
    Likes Received:
    28
    Best Answers:
    3
    Trophy Points:
    128
    #6
    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.
     
    ketting00, May 31, 2014 IP