1

I am currently building a web application that allows user to view all active sessions connected to their accounts, and if they want to, delete them individually - like Dropbox

enter image description here

One way I want to implement this is by sending links containing the actual session_key and embed them into the HTML like https://www.example.com/session/delete/SESSION_KEY

Would this be considered good practice or is there a better way to do this?

5
  • You will add a confirmation page, right? (i.e. the user will need to confirm the intended deletion)
    – grochmal
    Sep 18 '16 at 19:31
  • Is example.com suppose to be say Dropbox? Or is that your service? How will you ensure that the 3rd party itself invalidates the token?
    – thexacre
    Sep 18 '16 at 19:33
  • Why not simply use the ID (Primary Key) and then validate permissions in the delete handler? Sep 19 '16 at 9:43
  • @thexacre, what do you mean? are you worried about csrf attacks?
    – AlanSTACK
    Sep 20 '16 at 2:28
  • @SilverlightFox the primary key is the session key
    – AlanSTACK
    Sep 20 '16 at 2:28
1

Would this be considered good practice or is there a better way to do this?

No, this doesn't seem to be ideal.

The biggest problem I see is that you put a session id into the HTML of a page. It is best practice to make session cookies httpOnly to make XSS a bit harder to exploit. By putting the session id into the HTML, you leak that information in case of XSS, thus making httpOnly useless.

This may also be a problem if sensitive data is stored in a session, as someone who hijacked one session or account now has access to all sessions. The impact seems minor, but it doesn't seem ideal and may be a problem depending on the application.

Additionally, you don't have any CSRF protection which - while bad practice in general - doesn't have a security impact in this case as this isn't a very sensitive action and an attacker would need to know the session id, which they don't. Still, it doesn't seem ideal and also violates RESTful.

Finally, it's never a good idea to put sensitive data in a URL, it should instead be submitted via POST as it may otherwise leak in various ways. Again, this is likely not a security issue, as the data is useless as soon as it is used, but it doesn't follow best practices (and may be a problem, eg when the delete didn't work).

I would suggest to use ids that are independent of the actual session id, and to submit them via POST instead.

4
  • did you mean httpsONLY? (I apologize for a potentially trivial question)
    – AlanSTACK
    Sep 18 '16 at 20:14
  • @Alan no, httpOnly means that the cookie cannot be read out via javascript. This slightly mitigates XSS attacks (stealing cookies is an easy and quick way to exploit them). What you may be thinking of is the secure flag, which prevents cookies from being send over http (so if you have ssl, you should set both).
    – tim
    Sep 18 '16 at 20:17
  • I did not know of the httpOnly property, I always just assumed session cookies can be read like any other. Is there a special field or flag that marks a cookie as httpOnly?
    – AlanSTACK
    Sep 18 '16 at 20:19
  • 1
    @Alan yes, session cookies aren't really special, they can be read like any other. And yes, the flag is actually called httpOnly :) It looks like this in the HTTP header: Set-Cookie: SID=[THE_SID]; secure; HttpOnly. It depends on the language and framework you use if it is set automatically for session cookies (but it probably will be).
    – tim
    Sep 18 '16 at 20:24
1

If the session key is the session ID then no it would not be a good practice. The session ID is like gold. When you log in this ID is stored as a session cookie. If someone was to obtain this ID nothing would stop them from simply using the browser's dev tools to add the ID and they would be authenticated as that user without needing a username or password. The only place this should be exposed is as a browser session cookie since this is still a technical requirement for sessions.

Ideally these session IDs should have a unique reference key. And the key cannot recall a session but only be used to match the session ID in the session store to delete it. This key you could expose with little risk compared to the ID. This way the worst that comes of it is getting the session deleted.

2
  • What is your personal preference for this unique reference key then? UUID or hash(session_key)?
    – AlanSTACK
    Sep 18 '16 at 20:15
  • 1
    I would not hash what you could generate completely unique.
    – Bacon Brad
    Sep 18 '16 at 20:41

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.