If the cookie was saved in any way (maliciously or not: session hijacking, restored backup, etc), they are logged in. That’s exactly the problem, thanks for pointing it out.
If they had “logged off” (or closed the session), no amount of cookie resurrection would log them back in: the server would refuse that cookie session the same way it would refuse an expired password.
@7heo@tdawg, i only keep data from sites which i visit every day, no other, using Site Bleacher, it remove automatically cookies, local storages, IndexedDBs, service workers, cache storages, filesystems and webSQLs from all not whitelisted sites. This keeps clean the browser and HD.
Congratulations, you now have access to all the (not yet expired) sessions (i.e. accounts) your target ever used, because they follow(ed) the recommendations in the meme of OP and in your comment.
Depends on your (actually, their, for example if it implies ephemeral server sessions) definition of “incognito”. But if you mean “incognito” as in “private browsing”, it makes no difference (as it has no server side impact whatsoever).
A file is a file, a remote database entry is a remote database entry. You need both gone (and securely deleted, as in srm(1), to be really and irredeemably logged off).
Admittedly, secure deletion doesn’t really matter on the server side, as restoring deleted files require filesystem level access on the server, and if an attacker has that, you’ve got other things to worry about.
And what happens next time they load the site?
If the cookie was saved in any way (maliciously or not: session hijacking, restored backup, etc), they are logged in. That’s exactly the problem, thanks for pointing it out.
If they had “logged off” (or closed the session), no amount of cookie resurrection would log them back in: the server would refuse that cookie session the same way it would refuse an expired password.
@7heo @tdawg, i only keep data from sites which i visit every day, no other, using Site Bleacher, it remove automatically cookies, local storages, IndexedDBs, service workers, cache storages, filesystems and webSQLs from all not whitelisted sites. This keeps clean the browser and HD.
https://github.com/wooque/site-bleacher
Similar alternative
https://github.com/Cookie-AutoDelete/Cookie-AutoDelete
Yeah, so lemme show you a few tools since we’re on the topic of sharing.
winfr,testdisk, etc).Please log out from apps and websites!
What about incognito sessions?
Depends on your (actually, their, for example if it implies ephemeral server sessions) definition of “incognito”. But if you mean “incognito” as in “private browsing”, it makes no difference (as it has no server side impact whatsoever).
A file is a file, a remote database entry is a remote database entry. You need both gone (and securely deleted, as in
srm(1), to be really and irredeemably logged off).Admittedly, secure deletion doesn’t really matter on the server side, as restoring deleted files require filesystem level access on the server, and if an attacker has that, you’ve got other things to worry about.
Yeah, that’s what I was curious about, the security issues you mentioned as I wasn’t clear in my understanding until now. Thanks.