Session csrf_token versus LiveView csrf_token

Related to:

Anything in the session cannot be accessed by javascript in the browser, because the session cookie as the Secure and HttpOnly flags set on them, and you can read more about it here:

Restrict access to cookies

There are a couple of ways to ensure that cookies are sent securely and are not accessed by unintended parties or scripts.

A cookie with the Secure attribute is sent to the server only with an encrypted request over the HTTPS protocol, never with unsecured HTTPS. Even with Secure , sensitive information should never be stored in cookies, as they are inherently insecure and this attribute can’t offer real protection. Insecure sites (with http: in the URL) can’t set cookies with the Secure attribute (since Chrome 52 and Firefox 52).

A cookie with the HttpOnly attribute is inaccessible to the JavaScript Document.cookie API; it is sent only to the server. For example, cookies that persist server-side sessions don’t need to be available to JavaScript, and should have the HttpOnly attribute. This precaution helps mitigate cross-site scripting (XSS) attacks.

Here is an example:

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

So this means that in order to protect the fist call from LiveView to the server we need to give it another CSRF token, otherwise you would be leaking the session CSRF token to the html document, thus compromising the security of the session cookie, because any javascript on your page would be able to read it, just as the LiveView javascript is able to do.

It makes sense that you don’t want any javascript to be able to access session (or any other) cookies.
The csrf token that is sent to the liveview is copied from a meta tag that is rendered in the html source code just like a token would be rendered in a hidden form field.
I guess that meta tag was generated from session data right?
I would think that I would be able to validate the csrf token I get by calling Phoenix.LiveView.get_connect_params/1 against the one I get from the session argument in mount/3.
That way I could be sure the socket connection is safe just like I would know a post request came from my server.
Is that not the purpose of the csrf token?

The purpose of CSRF tokens are to give you some confidence that the request comes indeed from your browser app, but once they are used from an html tag, they are indeed a weak assurance for that purpose, but are better then nothing.

Anyway the ones used by Phoenix can be improved by using their encrypted tokens feature, and then checking in the backend that the token is correctly signed and not older then x amount of seconds, lets say 10 seconds.

With this approach you have more confidence that the request is indeed from your browser app, but 10 seconds is still plenty of time for it to be stolen and reused from malicious javascript code in your web page.

Now you can enhance the CSRF token even more by treating it as a nonce, aka it can be only used once, but this requires some logic in your backend to keep an :ets table with all CSRF tokens not expired, that you will check for in each request to see if it was already used, and if so you deny the request, despite the encrypted CSRF token be correctly signed and have not expired.

Once more this not guarantees you that the malicious javascript in your page was not the first one to use the encrypted CSRF token to make a request to your backend.

If you do all this then you are in a much safer place then the current standard approach, but remember that in the end of the day you cannot find a bullet proof solution, just one that is hard to bypass.

Thank you for your effort to help clearing things up.

So lets say that the purpose of CSRF tokens is to give me some confidence that the request comes from my browser app.
That’s exactly how I understand this technique so in this respect we are on the same page.

But what kind of request are we talking about?

a) mounting the liveview
b) liveview → render form → post stuff → got request

I am assuming that I should use this token: get_connect_params |> Map.get("_csrf_token") to validate mount/3 (option a), something along the lines of:

case token_from_connect_params do
  ^token_from_session -> :great_stuff
  _csrf_attack        -> :bad_news
end

Suppose the actual purpose is option b then I am misunderstanding all of this completely.
Probably someone can think of some obscure use case for option b.
To me that would be an edge case, so I would guess the purpose is option a.
so… how do I get rid of :bad_news ?

I did (finally) find a relation between the two csrf tokens:

Plug.CSRFProtection.dump_state()                       |  "0Nt0DUzw_86ttI3jIcNFPV61"
x: mount/3 -> session -> "_csrf_token"                 |  "0Nt0DUzw_86ttI3jIcNFPV61"
Plug.CSRFProtection.dump_state_from_session(a)         |  "0Nt0DUzw_86ttI3jIcNFPV61"
y: socket -> get_connect_params -> "_csrf_token"       |  "ZB4uAHB4KidmSmUrOQVbUgYSenMICUx0TPZ04-PP9rS_MLh8Oq45X_zE"
Plug.CSRFProtection.valid_state_and_csrf_token?(x, y)  |  true  <-- got match!

So I can validate mounting the liveview:

@impl true
def mount(%{} = request_params, %{} = session, socket) do
  case Map.get(session, "_csrf_token") do
    nil ->
      :ok = :secret_key_base
            |> socket.endpoint.config
            |> Plug.CSRFProtection.load_state(nil)

      token   = Plug.CSRFProtection.dump_state()
      session = Map.put(session, "_csrf_token", token)

      mount(request_params, session, socket)

    session_state ->
      connect_params = Phoenix.LiveView.get_connect_params(socket) || %{}
      csrf_token     = Map.get(connect_params, "_csrf_token")
      loading?       = is_nil(csrf_token)
      valid_token?   = Plug.CSRFProtection.valid_state_and_csrf_token?(
                         session_state, csrf_token
                       )

      state = case {loading?, valid_token?} do
                {true, false} -> :loading
                {false, true} -> :complete
                _csrf_attack  -> :error
              end

      {:ok, assign(socket, mount: state)}
  end
end

However, if this is correct, why is it not in the manual?
So probably it’s not correct.
And if it’s not correct, then what is the purpose of the csrf token?

The option a) refers to the CSRF token you mentioned here:

and my reply was base on that scope.

Now my suggested improvements may also be added to CSRF tokens for forms, but obviously there you cannot use a very short expire time for it.

I am still new to Elixir and Phoenix and just 1 month ago I decided to build a real project with it, thus I am still in the exploratory phase of all its security mechanisms, thus I welcome your findings regarding the CSRF token and I will explore them too.

To bear in mind that Phoenix Phoenix will check the Phoenix tokens for your in the incoming requests, but I have not explored the internals of it to see how it works and see if we have room for hardening it.

Well web-sockets can be attacked as anything else exposed to the internet, and if your site as some value for attackers you can bet that they will try to hack it, no matter if over web-sockets or regular http requests.

You can read more about testing web-sockets for security in this OWASP guide, that includes some examples with the OWASP Zed Attack Proxy.

You will not regret your decision to start a real project using Elixir and Phoenix
I am not new to Elixir and a huge fan, but when it comes to LiveView I’m also in the exploratory phase.
Unlike many other Elixir projects Phoenix has a lot of magic goblins walking around.
When I see stuff “pop up” (like %{"_csrf_token" => _} = session) I want to know all about it.
Sometimes it’s not easy to follow the money.
I think Phoenix and LiveView are works of genius.
Some things are a little unfortunate in my opinion, like for example non-specific variable names (“params”) and aliases imported by macros.
Using Phoenix seems simple, but there’s lots of stuff you need to know to make sense of the docs.
Anyway, Phoenix is absolutely awesome, so it’s worth it.

And if you haven’t already, please setup ci/cd and create tests for every public function.
Maybe it’s a lot of overhead but you will be very happy you did once your project becomes more complex.

I’m also curious about this. Not sure if I’ve completely understood, either.

My understanding that by default Phoenix does this:

1. The get_csrf_token() call in root.html.heex causes the server to generate a CSRF token, which it stores in the process dictionary.
2. As there is now a CSRF token in the process dictionary, Plug.CSRFProtection will also put the CSRF token in the session.
3. Subsequent responses will use the CSRF token from the session (cookie).

The result is that the HTML response contains a session cookie with the CSRF token (the first time), and also in the response body (every time), so it can be read by JS.

For LiveView, I’m also unsure. It looks like most of the components handle generating CSRF tokens themselves. The docs say:

The mount callback receives three arguments: the request parameters, the session, and the socket.
…
The session retrieves information from a signed (or encrypted) cookie.

But the CSRF token inside the session the mount call receives is not the one from the session cookie, it’s one generated by the live view

I had some time to look into this more.

It turns out this was all a misunderstanding, caused by getting confused by how Plug.CSRFProtection handles CSRF tokens internally.

How Plug.CSRFProtection handles CSRF tokens internally

Plug.CSRFProtection has an internal concept of “masked” (long) and “unmasked” (short) CSRF token. The one you get when you call get_csrf_token/0 is the masked one, but the one it stores in the session (which you see if manually getting the session or looking at the mount call, or inspecting the cookie) is the unmasked one. However, these are the same and you can check that they match as ingmar already did above:

I guess the masking is something to do with preventing timing attacks.

LiveView Components add the CSRF token automatically

form will automatically add the CSRF token (which it gets from the process dictionary, which is populated from the session cookie, as described in the previous post) to the form if it contains an action parameter. A form generated by mix phx.gen.live doesn’t contain action by default, as it’s assumed the form will be submitted via LiveView, but if you add it, the CSRF token will be added. For example

<.form for={@form} action={~p"/example/path"}>...</.form>

This form will include the masked/long CSRF token in a _csrf_token field by default, due to the presence of the action param.

Additionally, while looking into this, I also found this post which confused me, because what it described is all unnecessary - maybe it was an issue on older versions:

Now the issue described in that article also works out of the box with a link like this:

<.link method="delete", href={~p"/example/path"}>Delete</.link>

This generates a link with the relevant CSRF token included automatically.

To go full circle, the only thing I’m not sure about, is what the purpose of this is, considering components make their own calls to Plug.CSRFProtection to get the csrf token, so there doesn’t seem to be a need to pass it back from the browser: