2

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)...?

  • 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. – AndrolGenhald May 2 at 18:05
  • yes, just saw this and clarified, thanks! (it's remaining the same!) – benzkji May 2 at 19:06
  • it doesnt seem very clear if this is bad practice - half of answers tell yes, other half no... – benzkji May 3 at 9:44
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.

  • thanks, yes, I applied all the remaining "upgrading security" settings! I just wonderd if I configured something the wrong way round... – benzkji May 2 at 19:01
  • 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 at 11:12
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.

  • 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 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 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 at 20:05
  • 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 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?

  • 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 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? – Vipul Nair May 2 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 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 – Vipul Nair May 2 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 at 4:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.