Is sending a cookie with a sessionid in every HTTP response considered a bad practice?

Question

My Django application sets a set-cookie: sessionid=xxxx; expires=Thu, 16-May-2019 18:54:59 (and some more, like max-age and path) on every response. The sessionid remains the same until the session ends. I can see the purpose of this: By setting the expire time, the time when the browser should drop the cookie can well be controlled, and set to an up to date value every request made.

Two things:

• A security expert told me, that this is at least "un-normal" behaviour, normally the sessionid cookie should be set on login only, and the server would then just invalidate the cookie if it's no longer valid
• My current configuration is SESSION_EXPIRE_AT_BROWSER_CLOSE=True (https://docs.djangoproject.com/en/2.2/ref/settings/#std:setting-SESSION_EXPIRE_AT_BROWSER_CLOSE), so, the expire is no more a thing, right, and in theory, setting the cookie after login only would be ok.

But, I from my side see no downside on setting the header on every response - I mean, I pass the sessionid on to the server with every request already, and it just kinda returns it (with up to date expires)...?

UPDATE

This is called "Sliding Window", as some of the answers have stated. And, most say it is not bad practice, but some of you dont agree at all - topic remains oppiniated.

Answer 1

The Django default is secure.

Changing the way Django sessions work in a way that is not through a supported setting would be less secure, because if you replace django sessions with your own sessions module (or monkeypatch some code in Django's session module) you rely on yourself for security instead of relying on the Django community for security.

Your site should also be HTTPS-only and if so set SESSION_COOKIE_SECURE to True.

Answer 2

To best answer your questions, I need to cover a few areas to explain how COOKIES work and why it is useful to leverage them. This is based on my past experience with leveraging cookies in my past solutions.

COOKIES IN GENERAL

The purpose of COOKIES are to define something which gets sent in every request from the client to the server and back to the client in case those COOKIES get updated or told to clean up.

The purpose of persistent COOKIES is if the user closes the browser and re-opens it again, then the persistent COOKIES will be re-sent up in the next re-connection (stored only for that user's workstation login) so-as to resume without sending the user back to a LOGIN or SSO AUTH again because they have not yet expired.

This is beneficial because if you have a solution where you could have multiple TABS open to the SAME WEB SITE to multi-task work, you can re-use the COOKIES to resume and scale easily. Also, if the browser crashes, it can restart and resume easily to put the user back where they were last at as a convenience.

SESSION COOKIES

In my experience, it is common to have a SESSION COOKIE containing the SESSION ID and then the DOMAIN or SUB-DOMAIN to control security access by the page loaded by this DOMAIN or SUB-DOMAIN.

You shouldn't have to define an EXPIRATION on a SESSION COOKIE because the EXPIRATION should be set to 'Session' as the Server will know if it is expired or not.

Depending on your Web Server used, look for these type of SESSION EXPIRATION settings.

AUTH COOKIES

To guard against replay attacks, I've also seen AUTH COOKIES which have a SLIDING EXPIRATION. This means the EXPIRATION will SLIDE to a forward date/time of your EXPIRATION WINDOW for IDLE EXPIRATION.

IIS uses both SESSION COOKIES and AUTH COOKIES, but for whatever reason, IIS will not start SLIDING EXPIRATION on the AUTH COOKIE until it reaches 50% of the time to the initial EXPIRATION of the SESSION COOKIE. It then SLIDES EXPIRATION every request until the SERVER expires the SESSION.

SLIDING EXPIRATION FOR SESSION

Although good practice is to SLIDE EXPIRATION of the SESSION on the SERVER with every REQUEST received as you are actively communicating with the SERVER to support certain solutions where a system may need to remain up 24x7.

LOGOUT CAPABILITY

If concerned about persistent COOKIES, you can give the user a control to LOGOUT of the Web Site. When a LOGOUT occurs, the Web Server can request the Web Client to clear out all of it's related COOKIES.

Also, you can configure the OS to clear out the COOKIES on actual LOGOUT from their WORKSTATION.

Depending on your solution, you can adjust these rules to where if no user interaction on the CLIENT, the client can request to LOGOUT and cleanup based on your rules.

REPLAY ATTACK PROTECTION WITH AUTH COOKIES

As for protecting against a replay attack of all network traffic, the server should be validating the AUTH COOKIE VALUE to only use it once per REQUEST and changed to a new AUTH COOKIE VALUE which is has listed as available in a CATALOG maintained on the SERVER. (Multiple TABS can get tricky here so you have to decide how to deal with allowing multiple uses of the same AUTH COOKIE.)

COOKIES are protected (unlike the earlier years pre-2000) so-as to keep other web sites from jumping their gates and accessing your site's COOKIES illegally to hijack your LOGIN SESSION.

PERSISTENT COOKIES ARE SAFE TO USE

It is perfectly safe to use PERSISTENT COOKIES because you define the window of usefulness with an expiration date which should be around 15-20 minutes at most. SESSIONS on the Server should also only last at most 20 minutes before they SLIDE forward another 20 minutes after every request is received.

ANSWERING YOUR QUESTION

The SESSION COOKIE should have an EXPIRATION set to "Session". Configure the Web Server to manage the SESSION EXPIRATION for you and expire it after an IDLE TIME PERIOD passes.

The SESSION COOKIE should automatically be SENT by your CLIENT BROWSER without writing any special code.

Your WEB SERVER should manage the SESSION EXPIRATION for you, but the RESPONSE should always write the SESSION COOKIE and other COOKIES back to the CLIENT in every REQUEST to update them if they CHANGE.

RECENT ALTERNATIVE

With recent adoption of JWT Tokens, a JWT Token can serve both as SESSION and AUTH TOKEN as it contains an EXPIRATION and is SIGNED to protect against tampering. It also could be used to add some level of ZERO TRUST capability to your solution.

However, you have to write the code on the client and server to support it. Where-as the COOKIE use is automatic and common with most modern WEB SERVERS.

Answer 3

What purpose does updating the cookie on every request serve? The server must validate the cookie on every request anyway.

You say you see no downside in doing this. Ok, but what's the upside of doing it? I don't see one. Why do extra work for no gain? It just increases complexity.

Answer 4

My Django application sets a set-cookie: sessionid=xxxx on every response. I can see the purpose of this: By setting the expire time, the time when the browser should drop the cookie can well be controlled, and set to an up to date value every request made.

No, you are wrong. You are not setting the expire time for the cookie by doing that.

A security expert told me, that this is at least "un-normal" behaviour, normally the session id cookie should be set on login only, and the server would then just invalidate the cookie if it's no longer valid

Yes. You only have to give a session cookie to the user once and destroy it at logout - not change it with every request. Doing that serves no purpose and is an overhead to the server.

But, I from my side see no downside on setting the header on every response - I mean, I pass it on to the server with every request already...?

I don't get it. So you keep changing his session token and then migrate all the data that corresponds to one session to another? Isn't that just stupid?