LiveView Websocket Security

Phoenix Forum Questions / Help
, ,
1

Hello Everyone,

We are using LiveView to build a feature that displays some information in the admin dashboard of our Application, but we are not quite sure how to secure the websocket against access of non registered users.

Is the socket secure if we are using a signing salt and a Session key, having installed LiveView the exact Way thats recommended on Hexdocs.pm (we are using LiveView 0.8.1 currently)

Thank you very much in Advance

3 Likes
2

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

2 Likes
3

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
11 Likes
4

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?

1 Like
5

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.

5 Likes
6

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.

3 Likes
7

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?

8

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.

1 Like
9

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

10

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.

4 Likes
11

Here are the changes to enable this feature on top mix phx.gen.auth: https://github.com/dashbitco/mix_phx_gen_auth_demo/commit/1eebcaed8913dad9854acce201777bd92f0d1b0a

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

8 Likes
12

I’m using the LiveView and also approach phx.gen.auth.
The web execute login as usual, but how can we logout by using UserAuth.logout_user from LiveView (no @conn)? As there is the logout templates that are rendered underneath LiveView’s template.

13

The logout action should still be a regular controller action since LiveView cannot set cookies/session.

1 Like
14

Thank for your instant feedback, but the current logout link in template is:
<%= link "Logout", to: Routes.user_session_path(@conn, :delete), method: :delete %>

Then could we put the @conn to session at the login (as the usual) and use @conn in Liveview (mount(_, session, socket)) to put assigns to render the Logout link?

Imagine that we stand somewhere in Liveview and need the precisely way to perform logout action.

15

You should be able to generate the url just fine with both a conn or a socket. It just can’t be a live_patch or phx-click action, but it must be a proper http call to the server to log the user out.

2 Likes
16

After read the docs about links , I’ve changed the template and now no need to pass @conn:
<li><%= link "Logout", to: "/users/logout", method: :delete %></li>
But I still misunderstand why the default template _user_menu.html.eex in mix phx.gen.auth use @conn at: <%= link "Logout", to: Routes.user_session_path(@conn, :delete), method: :delete %>

Btw, I got the worth information at the commit Add security considerations section to docs.

1 Like
17

Using the route helpers is better because:

  1. you validate the route actually exists in your app.
  2. if you change the url, you don’t have to change the code

That said, this will just work too: <%= link "Logout", to: Routes.user_session_path(@socket, :delete), method: :delete %>.

3 Likes
18

So, it would be unwise to have live routes behind this pipeline then?

scope “/”, MyAppWeb do
pipe_through [:browser, :visitor, :redirect_if_user_is_authenticated]

live "/user/register", UserNewLive