Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fusion's existing session handling logic is a bit incorrect but it still works due to workarounds. sessions.NewCookieStore is supposed to receive a secure, random value: https://pkg.go.dev/github.com/gorilla/sessions#section-readme fusion currently passes it a fixed string baked into source. The result is that an attacker can forge a valid session token (they know the secret key) and send it to a fusion server, and the server would accept it. The reason this isn't a problem right now is that fusion works around this by storing an additional copy of the password in the session and then checking the password on each authenticated request. The current implementation works, but I think it's a bit more dangerous and complicated than what's ideal. Ideally, an attacker shouldn't be able to forge a session token at all. This change makes it so that the session cookie store derives session cookies using the server password as the secure secret. That way, an attacker can't forge session tokens unless they know the server password, but if they know the server password, it's game over anyway. Because we can trust the session store to reject requests with invalid session tokens, we don't need to store additional copies of the server password. We can trust that if the request has a valid session token, it's a token that the server created.
- Loading branch information