Session csrf_token versus LiveView csrf_token

Phoenix Forum Questions / Help
, ,
1

Does anyone know what is the point of:

let csrfToken = document.querySelector("meta[name='csrf-token']").getAttribute("content")
let liveSocket = new LiveSocket("/live", Socket, {params: {_csrf_token: csrfToken}})

when mount/3 in the LiveView receives a session containing another "_csrf_token" ?
And why are those tokens not the same, I am confused.

inspect Plug.Conn.get_session(assigns.conn, "_csrf_token")
>>> "Xebn1wL063P33DzixqzBBT6I"

document.querySelector("meta[name='csrf-token']").getAttribute("content")
>>> "EyMMBGcPHAMEez8BBCsKEA4HNjsNZncfKFnjVxP32Ho27opyvvLyO2AV"

def mount(%{} = _params, %{"_csrf_token" => csrf_token}, socket) do
>>> "Xebn1wL063P33DzixqzBBT6I"

socket |> Phoenix.LiveView.get_connect_params |> Map.get("_csrf_token")
>>> "EyMMBGcPHAMEez8BBCsKEA4HNjsNZncfKFnjVxP32Ho27opyvvLyO2AV"

What’s going on here?

1 Like
2

Related to:

3

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.

2 Likes
4

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?

5

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.

2 Likes
6

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?

1 Like
7

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.

8

You will not regret your decision to start a real project using Elixir and Phoenix :wink:
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.

2 Likes
9

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.

1 Like