0

In case someone visits an infected site his safety, if his cookies get stolen, may be compromised. Is there any abstract way to expire a session on the stolen session-id so that the id is practically useless?

I'm trying to protect myself on the client-side. A smart way to expire all the sessions without dealing with manually visit every site.

Is there such a tool?

1

If you still have the session id you can log out of the specific applications. A simple way of invalidating all sessions seems impossible. You could try to use some heuristic like the knowledge that a cookie with an SID set for domain example.com will have a logout page at example.com/logout or example.com/logout.html or something similar. Using this heuristic you could automatically visit all these logout pages and hope for the best. Maybe someone could write such a script and try to come up with a standardized way of invalidating session for which you have the SID.

There is no standard way of invalidating a session that you can rely on. Since each session id remains valid as long as the server keeps the session, there is not much you can do at the client side.

You can rely on server side measure which ties the session to your specific device as Steffen indicates but this is not always the case. Either way you can't do much.

If you can specify your scenario in more detail there might be other solutions.

  • I was trying to prevent session-hijacking quickly once I realized that I pressed a phising malicious link. silverlightfox in the comments provided me with a partial solution: bit.ly/1PQGKiB which perform this step for some popular sites. Every site that uses session-id's should provide also a standard way to expire and/or renew the session-id easily. – Mini Fridge Nov 24 '15 at 16:42
  • Did you enter any information in the phising website? You might need to change your passwords as well. I don't know if they can steal your SID's when clicking on this link. They could do some CSRF attack maybe. – Silver Nov 24 '15 at 19:25
1

It sounds like you're trying to prevent session-hijacking.

If you want to expire their session server-side you will need to give them a token (that's hard to guess) and tie an expiry time to it on their user record in your database. Since you are unable to guarantee the cookie is removed, you will need to have their browser send the cookie back and then you work out from your expiry time whether the cookie is indeed expired or not.

It's also recommended to refresh the token after user privileges have changed. I personally refresh the token between each page request to avoid missing anything.

Be sure to use SSL whenever transmitting the cookie or it will be able to be sniffed out.

There is more information on the OWASP Wiki Session Management Cheat Sheet

  • Useful information but I want manage my sessions as a client. Is that possible? – Mini Fridge Nov 19 '15 at 20:43
  • Didn't you say this was for you to clear your users of invalid cookies? The comments aren't there anymore oddly, but if you want to manage your personal cookies all you need to do is clear them via your browser. – Wrathbelle Nov 19 '15 at 20:45
1

Browsers have builtin settings to delete all cookies or particular cookies. Thus it is possible that a user can force the "immediately expire" (i.e. deletion) of cookies this way. What is not possible is that a visit to one site can force the deletion or expiration of cookies belonging to other sites.

EDIT: after the edit of the question it looks like that you effectively ask how the server can detect that the cookie is misused (i.e. session hijacking) and invalidate the cookie. Some sites do this by embedding some kind of browser fingerprint or the client IP address into the cookie so that use of the cookie from a different browser or IP gets detected. Once this is detected the cookie can simply removed from the database and thus gets invalid. For more information see OWASP about Session Hijacking.

  • Sounds reasonable. So what you are saying is that cookie expiration on the server side depends on the individual site's API that cookie belongs. – Mini Fridge Nov 19 '15 at 15:30
  • @MiniFridge: what I'm saying is that (apart from the user of the browser) only the origin of the cookie can change the cookie, which includes changing the expiration to now so that it gets deleted (but often only after the user closed the browser). – Steffen Ullrich Nov 19 '15 at 15:39
  • I guess you miss the point of my question so your answer above is not so helpful. Example: in case of a login cookie theft is there any way to invalidate this (without having you to logout manually), so the cookies become practically useless for the thief? – Mini Fridge Nov 19 '15 at 17:08
  • Only if it has been implemented by the application - for example, Facebook provides a list of active sessions, and allows users to close them individually. There isn't a standard way of doing it across multiple applications though - some would reset on login, some would have an option like Facebook, some would need the password to be changed. Are you really asking "can a user expire all open sessions for web applications, if they lose control of cookies on their local machine?"? – Matthew Nov 19 '15 at 17:16
  • @MiniFridge: I'be probably missed the point of your question because your original question had no clear point. After the edit now its more clear what you want, so see edited response. – Steffen Ullrich Nov 19 '15 at 18:08
1

Right, my interpretation of this is, and please correct if I'm wrong: user has had their laptop stolen, and they have lots of sessions on web sites open, perhaps because they checked the remember me box, or just like having lots of tabs open. User now wants to ensure that person who stole laptop can't use their sessions, by closing the remote sessions in some way.

They can't clear the cookies, because they don't have the device the cookies are stored on. Therefore, they are at the mercy of the web application developers. There are several possibilities here:

  1. Application provides a session management system, where user can log in, see active sessions, and close them if they want to. In this case, they should log in, close any other sessions and, just to be on the safe side, check whether any unwanted activity occurred on the account. An example of this type of site would be Facebook.
  2. Application only allows one instance of each user to be logged in at any given time. This is avoiding concurrent logins, and is generally a good thing to support if the application involves any form of transactions, whether financial or otherwise. In this case, simply log in. Any other active sessions will be terminated. Most banks operate like this, although they also tend to have short session expiry periods.
  3. If the application has a short session expiry (say the laptop was grabbed whilst you were making an online banking transaction), it's only a problem if they can use the account quickly. If they can't, the session will be terminated soon anyway.
  4. If the application combines a session token with a client identifier, that doesn't really help with this circumstance. In theory there could be applications where you can block specific client identifiers, but every instance of client identifiers I've personally come across have been in conjunction with a session management system.
  5. If none of the above are true, try logging into the application and changing your password. Well developed systems will expire any open sessions at that point. It may be worth testing this by opening two sessions of your own (perhaps in distinct browsers) and seeing if the session in the browser you don't use to change the password is closed when you do - the stolen session should do the same.
  6. If that doesn't work, there isn't much you can do - the application doesn't support session expiry in a user accessible way. Contact the application owner and ask if they can manually clear that session, but I wouldn't hold out much hope.

In short, there isn't a standard way which works for all sites if you can't delete the cookies.

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.