LiveView Websocket Security

there should be lots of different approach. But one approach is using Phoenix.Token to sign some user session data. and then in Socket.connect/3 we can verify if the token is valid. because the token is signed, it helps us against of tampering but if you don’t want people able to see what’s inside the token, you can also use Phoenix.Token.encrypt

Add your live route definition behind your regular :admin plug/pipeline that performs admin user authentication and you are all set. You can reference the user off the HTTP request, and fallback to the user_id in the session, which comes from a signed token on the client, so you are covered in both HTTP and WebSocket cases security wise:

  
  # router
  scope "/admin", ... do
    pipe_through [:browser, :admin]
    
    live "/", MyLive
  end

  # LV
  defmodule MyLive do
    def mount(params, %{"admin_user_id" => id}, socket) do
      {:ok, assign_new(socket, :current_admin, fn -> Accounts.get_admin!(id) end)}
    end
  end

I’m wondering if we’d need to talk about another factor of security for liveview:

A liveview process is long lived and potentially valid indefinitely if the connection is kept alive. For http one would check the validity of the user for each request, because it’s stateless. With stateful connections this can be more tiered, e.g. let the user read things for a certain time (or indefinitely) while e.g. checking validity for each writing operation. Even writing operations could be tiered to only creating data and destructive operations overwriting existing data. But I’m not really seeing those options used in the wild. Most people seem to fetch the user once and let it be valid for the lifetime of the liveview process. Isn’t this a potentially dangerous way of handling authentication?

Every operation you do against the database needs to be verified for user permission, you need to check if the user belongs to that organization, if they are the manager of a project, if they can access that chat room, etc. This logic is generally kept in the context, tied to the domain operation, so you go through it regardless if you are interacting with your domain via live views or controllers. In code, this means you should do:

Org.get_org_by_user(user, org_id)

Instead of:

Org.get_org(org_id)

Failing to scope this on regular HTTP requests can also be very troublesome, as it means a user can access any other organization.

The scenario you describe is only a concern if you are “preloading” permissions and storing it somewhere, which is not different from putting it in a cache, or an agent, live view state, etc.

And for things like user access, LV supports disconnecting any enabled socket. I even plan to submit changes to mix phx.gen.auth so we perform this disconnection by default on logout.

This is the part my question was targeted at - user sessions. If a session is compromised and the session key is removed from its storage on the server fresh http requests will fail to validate. For liveview existing connections either need to be closed if a certain session key is invalidated or at least have some means to over time detect that the session is no longer valid.

Edit:
I just looked at the example in detail: I’m not sure if a logout should close all connections scoped to the user. When I’m logging out of my desktop I won’t want to disconnect my laptop at the same time. For normal usage disconnecting by session key would seem like the way to go, possibly having a way to disconnect anything linked to a user account.

I am new to LV, therefore I may be misunderstanding something here, but to me this approach seems to let me run an enumeration attack by changing the id in the admin_user_id, thus letting me to get access to other admins?

The session data is signed on the server, returned to the client in the html, sent back to the server and validated. So no user tampering allowed.

Sorry I missed that the signature of mount/3 is mount(params, session, socket)… I am feeling a bit stupid now

You can also disconnect just one of the sessions. All you have to do is identify the connections per session token rather than user id. That’s what I am submitting to mix phx.gen.auth.

Here are the changes to enable this feature on top mix phx.gen.auth: Set the live_socket_id on login and disconnect on logout · dashbitco/mix_phx_gen_auth_demo@1eebcae · GitHub

It is really straight-forward and it is per session (i.e. it doesn’t disconnect all sessions, only the current one).