4 ms·

Be careful, websockets are tricky to secure and get right. It's easy to do something like forget to check the origin and now you've opened up a whole class of

Be careful, websockets are tricky to secure and get right. It's easy to do something like forget to check the origin and now you've opened up a whole class of cross-site websocket scripting attacks. I love the idea of easy access and nice UI to prod machines, but put it behind a secure proxy or VPN layer and not facing the public internet.

dnautics 6y ago
That's very reasonable.
bcardarella 6y ago
Phoenix Channels accounts for many of these attack vectors. Livebook uses Phoenix LiveView which is built on Phoenix Channels.
wrren 6y ago
'Connect to an existing node' is likely implemented using ERTS (http://erlang.org/doc/reference_manual/distributed.html http://erlang.org/doc/reference_manual/distributed.html). So you're basically connecting to the runtime of the target node. The security model for ERTS isn't great, though, so your point stands. All you need is a matching secure cookie and you can connect and run any commands you want.
- qbasic_forever 6y ago
  Yep, and then the temptation to fix it is to roll your own homebrew auth over websockets... which is super risky.
  - dnautics 6y ago
    I imagine that such a solution would be a public package/extension with eyes on it.
- lostcolony 6y ago
  To put context on that - it's still TLS, the cookie is just a password. The problem is that it's one password for the node network, and you either have it, or you don't. So there's no real administrative control over access; it's shared password.
  - qbasic_forever 6y ago
    And a browser can be tricked into sending the cookie if you accidentally misconfigure the server. You will have no indication or warning of this happening, from either the client or server side, if you get it wrong.
    - lostcolony 6y ago
      >> if you accidentally misconfigure the server Sure, but I mean...
    - gallexme 6y ago
      If u use live book to print the erlangs distribution cookie, u still would need to steal the inter nodes certificate and be on the server network to do any shenanigans But how would u get into livenotebook in first place if u shouldn't have access to the container it and the connected nodes run on? I mean u can easily destroy a production system with couple erlang commands
exikyut 6y ago
Hmmm. Nginx has an auth_subrequest module that yeets all the cookies in a requests over to a configured URL in a server-initiated subrequest (hence the name), then proceeds with the original request only if the subrequest returns 200 OK. The module works with any type of incoming request, including FastCGI and reverse proxy situations. The idea is that some config magic turns the 401 into a 302 redirect that walks you through a single-signon page, then you get redirected back to wherever you left off. However since you can make failed requests do just about anything you could technically reroute the request to a WebSocket server that just serves error responses or something, but that feels very... wronky. The module does feel somewhat unwieldy to use in general as well, although this may be due to general unfamiliarity on my part with Nginx's way of doing things (which I'd summarize as "AAAAAAaaaaaaaa (aaa!)"). (The whole `if`-statements-can-SEGV thing etc.) The module can only return 200 (allow original request through) or 401 (deny original request); any other response causes nginx to cancel the original request and return 503. (In case of 401, anything else, or error, the FastCGI server or upstream never sees a connection at all.) It's possible to pass interesting state information such as a username or non-opaque session token from the subrequest to the main request by capturing subrequest response headers then injecting them as request headers into the main request, but this is sufficiently into the weeds (and unlike any existing system Web developers would typically have experience with) that I have a strong tendency to just go \ N O \, but considering that it is admittedly an obscure yet established corner of nginx's configuration, I figured I'd say something for completeness... for the benefit of the 2 people still reading up to this point. :D I've incidentally been trying to figure out how to set up a simple BeyondCorp-esque system with it for a while now (for remote access to home systems, so focusing mostly focusing on brain-dead simplicity), but the giant brick wall I keep running into is how to a) make things auth-aware, b) keep the cookie properly opaque, and b) prevent everything from exploding horribly if auth_subrequest gets turned off. The only method I can think of to enable (b) (so that individual services don't have to duplicate auth logic, kind of defeats the point) is to pass headers out from the subrequest, which then breaks (c) (making it possible to access things directly). A small microservice that handles the cookie side of things and makes HTTP requests itself starts looking like a breath of fresh air...
- rad_gruchalski 6y ago

dnautics 6y ago

That's very reasonable.

bcardarella 6y ago

Phoenix Channels accounts for many of these attack vectors. Livebook uses Phoenix LiveView which is built on Phoenix Channels.

wrren 6y ago

'Connect to an existing node' is likely implemented using ERTS (http://erlang.org/doc/reference_manual/distributed.html http://erlang.org/doc/reference_manual/distributed.html). So you're basically connecting to the runtime of the target node. The security model for ERTS isn't great, though, so your point stands. All you need is a matching secure cookie and you can connect and run any commands you want.

qbasic_forever 6y ago
Yep, and then the temptation to fix it is to roll your own homebrew auth over websockets... which is super risky.
- dnautics 6y ago
  I imagine that such a solution would be a public package/extension with eyes on it.
lostcolony 6y ago
To put context on that - it's still TLS, the cookie is just a password. The problem is that it's one password for the node network, and you either have it, or you don't. So there's no real administrative control over access; it's shared password.
- qbasic_forever 6y ago
  And a browser can be tricked into sending the cookie if you accidentally misconfigure the server. You will have no indication or warning of this happening, from either the client or server side, if you get it wrong.
  - lostcolony 6y ago
    >> if you accidentally misconfigure the server Sure, but I mean...
  - gallexme 6y ago
    If u use live book to print the erlangs distribution cookie, u still would need to steal the inter nodes certificate and be on the server network to do any shenanigans But how would u get into livenotebook in first place if u shouldn't have access to the container it and the connected nodes run on? I mean u can easily destroy a production system with couple erlang commands

exikyut 6y ago

Hmmm. Nginx has an auth_subrequest module that yeets all the cookies in a requests over to a configured URL in a server-initiated subrequest (hence the name), then proceeds with the original request only if the subrequest returns 200 OK. The module works with any type of incoming request, including FastCGI and reverse proxy situations. The idea is that some config magic turns the 401 into a 302 redirect that walks you through a single-signon page, then you get redirected back to wherever you left off. However since you can make failed requests do just about anything you could technically reroute the request to a WebSocket server that just serves error responses or something, but that feels very... wronky. The module does feel somewhat unwieldy to use in general as well, although this may be due to general unfamiliarity on my part with Nginx's way of doing things (which I'd summarize as "AAAAAAaaaaaaaa (aaa!)"). (The whole `if`-statements-can-SEGV thing etc.) The module can only return 200 (allow original request through) or 401 (deny original request); any other response causes nginx to cancel the original request and return 503. (In case of 401, anything else, or error, the FastCGI server or upstream never sees a connection at all.) It's possible to pass interesting state information such as a username or non-opaque session token from the subrequest to the main request by capturing subrequest response headers then injecting them as request headers into the main request, but this is sufficiently into the weeds (and unlike any existing system Web developers would typically have experience with) that I have a strong tendency to just go \ N O \, but considering that it is admittedly an obscure yet established corner of nginx's configuration, I figured I'd say something for completeness... for the benefit of the 2 people still reading up to this point. :D I've incidentally been trying to figure out how to set up a simple BeyondCorp-esque system with it for a while now (for remote access to home systems, so focusing mostly focusing on brain-dead simplicity), but the giant brick wall I keep running into is how to a) make things auth-aware, b) keep the cookie properly opaque, and b) prevent everything from exploding horribly if auth_subrequest gets turned off. The only method I can think of to enable (b) (so that individual services don't have to duplicate auth logic, kind of defeats the point) is to pass headers out from the subrequest, which then breaks (c) (making it possible to access things directly). A small microservice that handles the cookie side of things and makes HTTP requests itself starts looking like a breath of fresh air...

rad_gruchalski 6y ago