4 ms·

Holy cow. Browser devs seem to become crazier by the minute. Combine this with the lack of a same-origin policy in the JavaScript websocket API and you can real

Holy cow. Browser devs seem to become crazier by the minute. Combine this with the lack of a same-origin policy in the JavaScript websocket API and you can really poke around in the local network.

wereHamster 12y ago
Well, for websockets it's up to the server to check if the connection should be accepted or not. Same as in CORS whnere the server sais who is allowed to access the resources, not the browser.
geofft 12y ago
There's no SOP in the JS websocket API because websockets are a newly-designed protocol specifically for the use case of being called from JS. If you have websocket servers on your local network (... although, why?) they know they should be checking origin.
- jessaustin 12y ago
  If you have websocket servers on your local network... Maybe those aren't common, but it's very common to have something that looks just like one (speaks HTTP on port 80), which is called a web server. That might be embedded in your router or other device, or it may be a configuration interface for your POS, or it might be hiding in some other dark and unpatched corner that was formerly hidden behind a firewall. Of course it would be nice if the server simply doesn't respond (while writing alarms to the log) when it sees an Upgrade: websocket header, but can we be sure that all our hidden servers are so well-behaved?
  - geofft 12y ago
    The intention of the WebSocket protocol is that the handshake is sufficiently unlike HTTP that nobody could make a meaningful response to it by mistake. As for non-meaningful responses, isn't this equivalent to using <img src="http://192.168.1.1/admin?action=evil"> http://192.168.1.1/admin?action=evil"> to send an HTTP request? That's also not restricted by same-origin, and never has been and never will be. You get the same result -- you cause an HTTP request to be sent somewhere, and the response isn't useful to you nor is the contents of the response visible to you, but the request and its side effects still happen. I'm not super well-versed in websocket design, so I'm happy to be convinced I'm wrong, but that's my understanding of why it works the way it does.
    - jessaustin 12y ago
      Ahhh, you're right. I guess this just ends up being another way of "fingerprinting" the hosts on the local network, which really is kind of minor.

Holy cow. Browser devs seem to become crazier by the minute. Combine this with the lack of a same-origin policy in the JavaScript websocket API and you can really poke around in the local network.

wereHamster 12y ago

Well, for websockets it's up to the server to check if the connection should be accepted or not. Same as in CORS whnere the server sais who is allowed to access the resources, not the browser.

geofft 12y ago

There's no SOP in the JS websocket API because websockets are a newly-designed protocol specifically for the use case of being called from JS. If you have websocket servers on your local network (... although, why?) they know they should be checking origin.

jessaustin 12y ago
If you have websocket servers on your local network... Maybe those aren't common, but it's very common to have something that looks just like one (speaks HTTP on port 80), which is called a web server. That might be embedded in your router or other device, or it may be a configuration interface for your POS, or it might be hiding in some other dark and unpatched corner that was formerly hidden behind a firewall. Of course it would be nice if the server simply doesn't respond (while writing alarms to the log) when it sees an Upgrade: websocket header, but can we be sure that all our hidden servers are so well-behaved?
- geofft 12y ago
  The intention of the WebSocket protocol is that the handshake is sufficiently unlike HTTP that nobody could make a meaningful response to it by mistake. As for non-meaningful responses, isn't this equivalent to using <img src="http://192.168.1.1/admin?action=evil"> http://192.168.1.1/admin?action=evil"> to send an HTTP request? That's also not restricted by same-origin, and never has been and never will be. You get the same result -- you cause an HTTP request to be sent somewhere, and the response isn't useful to you nor is the contents of the response visible to you, but the request and its side effects still happen. I'm not super well-versed in websocket design, so I'm happy to be convinced I'm wrong, but that's my understanding of why it works the way it does.
  - jessaustin 12y ago
    Ahhh, you're right. I guess this just ends up being another way of "fingerprinting" the hosts on the local network, which really is kind of minor.