4

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.

3
  • 2
    To clarify, when you say it sets set-cookie: sessionid=xxxx on every response, does it give the sessionid the same value, or a new value every time? Some of the answers seem confused about this. May 2, 2019 at 18:05
  • yes, just saw this and clarified, thanks! (it's remaining the same!)
    – benzkji
    May 2, 2019 at 19:06
  • it doesnt seem very clear if this is bad practice - half of answers tell yes, other half no...
    – benzkji
    May 3, 2019 at 9:44

4 Answers 4

2

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.

2
  • thanks, yes, I applied all the remaining "upgrading security" settings! I just wonderd if I configured something the wrong way round...
    – benzkji
    May 2, 2019 at 19:01
  • 1
    I'm not a big fan of this answer because it's very specific to Django and does not answer the general case of the question, but indeed, if the Django devs took care to make this secure, it's probably best to just leave the default instead of rolling your own.
    – Luc
    Sep 30, 2019 at 11:12
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.

1
  • thank you, for your (long) answer. I know how cookies work ;-) so, you say it's not bad practice. but I dont see a explantation why it isn't?
    – benzkji
    Jan 8, 2023 at 19:58
0

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.

4
  • I do no extra work, it's Django that does it. I wonder if it could be disabled ;-) at least in SESSION_EXPIRE_AT_BROWSER_CLOSE mode.
    – benzkji
    May 2, 2019 at 19:00
  • The upside is an up to date expires value. I know...that could and should be done server side as well.
    – benzkji
    May 2, 2019 at 20:04
  • Do you see a downside, security wise? If an attacker can read my traffic, he can get the sessionid from the request anyway.
    – benzkji
    May 2, 2019 at 20:05
  • 1
    While I agree, this does not answer the question. "Is climbing a tree considered bad practice?" is not answered by "why would you climb a tree, what's the upside?"
    – Luc
    Sep 30, 2019 at 11:09
0

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?

8
  • sorry, clarified my question, it does set expire. also, the sessionid remains the same, until the session ends. it's just that in the response, there is always the set-cookie header...
    – benzkji
    May 2, 2019 at 19:04
  • But why would you set-cookie again and again?Give it one expiry.And does the session id change with every request?
    – yeah_well
    May 2, 2019 at 19:05
  • As I clarified, the sessionid remains the same, across all requests. If setting one expiry, it will just end then. This just seems not how Django works...it will extend the sessionid's expiry, with every request...as far as I understand.
    – benzkji
    May 2, 2019 at 19:10
  • "If setting one expiry, it will just end then" thats not how it is supposed to work.You set an expiry in the future and the session remains until then.When the user logs out you set the session expiry in the past or delete the session cookie.That how it was taught to me
    – yeah_well
    May 2, 2019 at 19:14
  • 1
    It's called "sliding window." If you want a cookie that expires 10 minutes after your last interaction, the only way to do it is to set a new cookie with each interaction. This is not at all uncommon.
    – John Wu
    May 4, 2019 at 4:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .