1

I wanted to implement login system using flask framework. I managed to do this using sessions and set them to expire after 31 days and it works (sessions are created using server secret key, timestamp and cryptography by flask).
But there is one thing that is concerning me and that is session id that was created before can still be used before it is expired e.g:

  1. User logs in and session id is: e.g:eyJ1c2VybmFtZSI6InBhbWl4In0.ZcIFkA.9VeEJ4_nxQgCNkijO6GLtSNse3c
  2. User logs out which means that session is deleted but only locally because cryptography will make it expire after 31 days since the creation, it means previous token is still valid.
  3. User logs in and session id is newly generated. But the problem is that session from first step is still valid and I can use it again.

I believe vulnerability that I'm describing is called replay attack. I have few questions regarding that topic:

  1. Should I even worry about it?
  2. If it is considered vulnerablity,how can I try to get rid of this?
  3. Is it good idea to create new column in database in User table(the same that stores credentials like username and password) called 'session id'? That way I can store the latest valid session id so when user makes request it can compare the session id that he sent with the one in the database. I am not sure if it is good idea because of efficiency reasons.
Improve this question
2
  • 2
    Its not a good idea to write your own security, there are loads of frameworks out there, use an off the shelf solution which will have been tested for all the hacks you won't know about.
    – Ewan
    Commented Feb 6 at 11:03
  • Have you considered using the session id as an input when creating of the token? You would also need to verify the session matches when checking the token.
    – JimmyJames
    Commented Feb 7 at 15:54

1 Answer 1

Reset to default
3

First, model the situation correctly. We have a one-to-many relationship between user and sessionid. An attribute of a session is its expiration timestamp. So we will want a three-column table with FK relationship out to the user table.

  1. ... session from first step is still valid

Well, that's a bug, or a design flaw.

The way you have arranged things, you can't rely on embedded expiry time within a session id. You need to consult the expiration recorded in the DB for each request (or at least a cached copy of it).

  1. User logs out which means that session is deleted but only locally

No, that is just wrong. See item (3.) that you wrote. A "log out" operation cannot have effect solely on the client, in the system you describe.

Logging out must cause the server to issue a database UPDATE of the expiration timestamp so it matches current wallclock. That prevents subsequent requests from successfully launching a replay attack.

There are other ways to mitigate such problems. I'm just trying to adjust your description so it is self consistent.

A midnight cron job on the server should probably tidy up that session table, to keep it from growing without bound. Issue a DELETE ... WHERE the expiration is more than 31 days in the past, as those rows are no longer of interest. Your description of the sessionid suggests that it mentions a timestamp, and since it is more than a month old server won't honor such sessionids, it can decide that without even consulting the DB.

Improve this answer
1
  • +1 for "cannot have effect solely on the client". The client should be completely untrusted and everything received from it treated as suspect.
    – Phill W.
    Commented Feb 7 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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