The main risk of a persistent session is increased exposure for any existing client-side vulnerabilities (e.g. XSS, CSRF, session fixation, etc).
That is, any malicious site targeting your users through exploits for the above would be more likely to succeed because the user is left logged in.
With remember-me the above could apply too - Say the long-term remember-me token is exchanged for a session token automatically per request.
e.g.
in the request the browser sends
Cookie: remember-me=32132213312132
and the server automatically issues a session token for this request because the token validates. It also replies with their new session token for subsequent requests to use in this session:
Set-Cookie: session=asdkalkjdjsaddsajdsal
This shows that even though a separate cookie is used for long term access, because it is automatically exchanged it will also aid cross-domain exploits in attacking user sessions.
You could mitigate this by using OAuth2 style refresh tokens.
Then if the attacker tries an CSRF attack such as
<img src="https://example.com/transfer_money?to_acc=2321321&amount=1000000" />
it would not automatically succeed because the refresh token alone is not enough to authenticate the request (remember-me
) - it must be exchanged for an access token (session
).
e.g. if the user visits your site, there could be another explicit step to get the session
token to represent an active, logged-in user:
<form method="post">
<input type="hidden" name="anti-csrf" value="asddadaddasa242421fsas" />
</form>
The anti-csrf token is attached to the refresh token in the server-side database, preventing a CSRF exploit from being used to get the token ahead of the attack. The above should be manually submitted by the user to prevent an attacker from opening the page in a popup or within an IFrame.
Only after all of the above validates does the server reply with an access token (session
):
Set-Cookie: session=asdkalkjdjsaddsajdsal
Of course your site should already mitigate against XSS, CSRF and the like, however this is a defence-in-depth approach to guard against long term tokens being set that have a higher chance of compromising a user because their login is more likely to be active should they be attacked.