Destroying sessions on user logout.

  • (3 Pages)
  • +
  • 1
  • 2
  • 3

32 Replies - 2624 Views - Last Post: 31 March 2015 - 07:10 PM

#1 Atli  Icon User is offline

  • Enhance Your Calm
  • member icon

Reputation: 4238
  • View blog
  • Posts: 7,216
  • Joined: 08-June 10

Destroying sessions on user logout.

Posted 30 March 2015 - 04:34 PM

Mod note: This discussion was split from this help thread, so not to hijack it.




Is there a specific reason why you are destroying the session?
In this situation, it should suffice to just unset the "username" element.
unset($_SESSION["username"]);



If you ever start using the session for purposes other than keeping track of logins, it would be safer to leave the session itself intact, and just unset the field(s) specific to the login functionality.

I generally find it best to be specific when deleting data. Avoids accidentally losing data you don't want to lose.

This post has been edited by Atli: 31 March 2015 - 07:08 AM


Is This A Good Question/Topic? 0
  • +

Replies To: Destroying sessions on user logout.

#2 benanamen  Icon User is offline

  • D.I.C Head

Reputation: 13
  • View blog
  • Posts: 119
  • Joined: 28-March 15

Re: Destroying sessions on user logout.

Posted 30 March 2015 - 04:59 PM

The manual gives the exact reason to destroy the session:

FROM THE MANUAL
session_destroy() destroys all of the data associated with the current session. It does not unset any of the global variables associated with the session, or unset the session cookie.


In order to kill the session altogether, like to log the user out, the session id must also be unset.
Was This Post Helpful? 0
  • +
  • -

#3 Atli  Icon User is offline

  • Enhance Your Calm
  • member icon

Reputation: 4238
  • View blog
  • Posts: 7,216
  • Joined: 08-June 10

Re: Destroying sessions on user logout.

Posted 30 March 2015 - 05:04 PM

That doesn't really answer my question. I'm wondering why he would destroy it in the first place, not how to destroy it properly.

Like I say, there is no need to actually destroy the session to achieve the functionality he's going for here.
Was This Post Helpful? 0
  • +
  • -

#4 benanamen  Icon User is offline

  • D.I.C Head

Reputation: 13
  • View blog
  • Posts: 119
  • Joined: 28-March 15

Re: Destroying sessions on user logout.

Posted 30 March 2015 - 05:34 PM

If it is not destroyed and the browser has not been closed, the session still exists in the browser in PHPSESSID cookie and the session file that goes with it is still on the server. All unset does is delete the data from the session file on the server. The session file still exists on the server and the browser maintains the correct connection to that file.

If your not concerned about security, then you dont need to destroy the session. If someone logs into your site from an internet cafe or library, logs out but doesnt close the browser, do you really want a valid session id available to a stranger? You might want to learn about:
Predictable session token;
Session Sniffing;
Client-side attacks (XSS, malicious Javascript Codes, Trojans, etc);
Man-in-the-middle attack
Man-in-the-browser attack

You can start here: https://www.owasp.or...ijacking_attack

If you dont have firebug, install it and test it out.
Was This Post Helpful? 0
  • +
  • -

#5 Atli  Icon User is offline

  • Enhance Your Calm
  • member icon

Reputation: 4238
  • View blog
  • Posts: 7,216
  • Joined: 08-June 10

Re: Destroying sessions on user logout.

Posted 30 March 2015 - 06:09 PM

I'm aware of all of this, although I'm curious how you connect those five security threats you listed to this specific topic? - Predicting or sniffing the session ID would be rather pointless if the browser still has the session cookie, since you could just read it from there; and MitM and MitB attacks aren't really something you can combat by refreshing the session ID, they go way beyond that. Also not really seeing how those client-side threats are related; they wouldn't really be affected by whether or not the user is using a fresh session ID...


The session is essentially a dumb storage array. unset deletes the login token from that array, thus requiring whoever is using the browser to log back in. Whether or not the next person on that computer is using the same session ID makes no difference; that person will still have to know a valid login to access the site.

A stolen or shared session ID is only a threat if there is something in that session that poses a threat. By cleaning out user-specific data in the logout procedure (in this case: the username) the session doesn't contain anything that would be a threat.

View Postbenanamen, on 31 March 2015 - 12:34 AM, said:

If you dont have firebug, install it and test it out.

Cute.
Was This Post Helpful? 1
  • +
  • -

#6 benanamen  Icon User is offline

  • D.I.C Head

Reputation: 13
  • View blog
  • Posts: 119
  • Joined: 28-March 15

Re: Destroying sessions on user logout.

Posted 30 March 2015 - 06:20 PM

I will get back to you when I want to get into a pointless argument. Advising anyone to leave an open session says enough about what you know.

This post has been edited by benanamen: 30 March 2015 - 06:22 PM

Was This Post Helpful? -1
  • +
  • -

#7 Atli  Icon User is offline

  • Enhance Your Calm
  • member icon

Reputation: 4238
  • View blog
  • Posts: 7,216
  • Joined: 08-June 10

Re: Destroying sessions on user logout.

Posted 30 March 2015 - 06:34 PM

View Postbenanamen, on 31 March 2015 - 01:20 AM, said:

I will get back to you when I want to get into a pointless argument. Advising anyone to leave an open session says enough about what you know.

It's not an argument, mate. Just a discussion.

If you have any points/facts to counter my thinking, please do so. I'm not above admitting when I'm wrong (which happens every now and then), but don't expect me to just accept a blanket, unsupported statement like that as truth. If your position really is as strong as you seem to believe, it shouldn't be very difficult to counter me on this.
Was This Post Helpful? 0
  • +
  • -

#8 benanamen  Icon User is offline

  • D.I.C Head

Reputation: 13
  • View blog
  • Posts: 119
  • Joined: 28-March 15

Re: Destroying sessions on user logout.

Posted 30 March 2015 - 07:00 PM

Ok mate, misunderstood. I never said you were wrong. My point was that if you don't destroy the session, it is still left open as long as the browser has not been closed. It is clear from your previous reply that you know and understand that so we are in agreement. As far as the precise security implications of that, I will have to get back to you another time as I am short on time at the moment.

The other items I mentioned were not meant to apply directly to this.
Was This Post Helpful? 0
  • +
  • -

#9 benanamen  Icon User is offline

  • D.I.C Head

Reputation: 13
  • View blog
  • Posts: 119
  • Joined: 28-March 15

Re: Destroying sessions on user logout.

Posted 31 March 2015 - 09:29 AM

To be clear, this discussion is regarding destroying/not destroying a session on logging out of an app.

So, lets start with what you said here:

Quote

A stolen or shared session ID is only a threat if there is something in that session that poses a threat. By cleaning out user-specific data in the logout procedure (in this case: the username) the session doesn't contain anything that would be a threat.


You are half right. This part is true: "the session doesn't contain anything that would be a threat."

An empty active session is not the threat. There is nothing there, so an attacker cannot login at this point.

The threat is when the attacker has access to the live session from user A and is able to get user B,C, or D to log in using that same session. There are several ways that can be done and they can get quite complex, but the simplest way is getting user B,C, or D to login using the known active session from a link. I am pretty sure everyone reading this has gotten spam that appears to come from from a bank or paypal saying they need to login and check their account or whatever. That is the most basic way the threat begins.

So, user B falls for the email and clicks the link which is encoded with the session id known to the attacker and logs in. Now the "empty" session is no longer empty and has valid login data for user B.

Since the attacker has access to the session, he can now impersonate user B with a valid login. Depending on the app the attacker has access to will determine what kind of damage he can do. In the case of a banking site, he can transfer money out of user b's account since he is logged in as a valid user.

An additional threat now comes into play. Many people use the same login and password for every site. The attacker now potentially has a username and password used by user B. The attacker can now go to popular sites such as facebook or whatever and try the known login info at those sites. It is very likely the attacker is going to get in since user B always uses the same login info. And thus, the potential for damage continues.

That is why you must destroy the session completely when logging out of an app.
Was This Post Helpful? 0
  • +
  • -

#10 ArtificialSoldier  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1789
  • View blog
  • Posts: 5,700
  • Joined: 15-January 14

Re: Destroying sessions on user logout.

Posted 31 March 2015 - 10:01 AM

I'm going with Atli's argument here, I don't see any functional reason to completely destroy a session. Unsetting each session variable you set is enough, I cannot think of a real-world example where an open empty session is a security threat. Many applications or sites will create an empty session the first time you load any page anyway, just in case it needs it later. That also is not a threat, and is functionally the same as clearing out each session variable you set.

Quote

I am pretty sure everyone reading this has gotten spam that appears to come from from a bank or paypal saying they need to login and check their account or whatever. That is the most basic way the threat begins.

Phishing and session hijacking are not related. Phishing scams try to direct someone to a fake site made to look exactly like the target site, people enter their credentials and then the attacker has the credentials.

Quote

So, user B falls for the email and clicks the link which is encoded with the session id known to the attacker and logs in.

You're talking about a completely different vulnerability, where the session ID is passed in the URL instead of only using cookies. If that feature is disabled, which it should be, then your attack fails.

Quote

The attacker now potentially has a username and password used by user B.

I don't understand how they would get access to the user's password in your hypothetical scenario. Is the hypothetical banking application printing the user's password on the page somewhere? Is it saving the password in the session and then printing the session data?


I understand what you're getting at, that someone could use their open session to try and send to someone else that they want to attack, but a decent application should not allow that, it shouldn't start a session because of a session ID in the URL. Just having that option disabled would mitigate the threat by itself. Maybe an alternative attack would be to send someone to a link you control where you set a cookie for the target domain and then redirect them, but that's getting back into phishing attacks and someone clicking on a link to a site that they don't recognize.

There are several ways to avoid session hijacking though, the major one is to regenerate the session ID on each request. That will stop all of these attacks dead. The main reason I see for not using session_destroy is with larger applications where some module or plugin or whatever is storing data in the session also and you don't want to delete everything that you didn't set. Ideally you should only be deleting what your code set.
Was This Post Helpful? 0
  • +
  • -

#11 benanamen  Icon User is offline

  • D.I.C Head

Reputation: 13
  • View blog
  • Posts: 119
  • Joined: 28-March 15

Re: Destroying sessions on user logout.

Posted 31 March 2015 - 10:43 AM

@ArtificialSoldier,

Quote

Phishing and session hijacking are not related.


I am not talking about Phishing at all and sending someone to a fake site. I am talking about a real site that is badly coded. A banking site is not likely to store a username AND password in the session, it was just an example. There are indeed noob apps that do store the login data in the session.

Quote

I cannot think of a real-world example where an open empty session is a security threat.

I clearly said that an open empty session is not the threat itself. The problem begins when someone other than the person that opened the session has access to it.

Quote

You're talking about a completely different vulnerability, where the session ID is passed in the URL instead of only using cookies. If that feature is disabled, which it should be, then your attack fails.

Of course it should be disabled. I am talking about noob programming. Most threats can be stopped or hindered. If not, I would be out of business.


Quote

I don't understand how they would get access to the user's password in your hypothetical scenario. Is the hypothetical banking application printing the user's password on the page somewhere? Is it saving the password in the session and then printing the session data?


Ok, the badly coded site would be saving the username and password to a session. Even if it is just the username which is very common, you have 50% of the login data stored in the session. There is no need to print the session data anywhere. It is already in plaintext in a file on the server.

Quote

I understand what you're getting at, that someone could use their open session to try and send to someone else that they want to attack, but a decent application should not allow that,

You are correct, but we are by no means talking about a decent application.

Quote

but that's getting back into phishing attacks and someone clicking on a link to a site that they don't recognize.
I am not referring to phishing at all. The link example was the most basic example there is. The other ways are much to complex and technical for me to want to get into here. Regarding all your references of what can be done to mitigate the problem, I know. We are still talking about a badly coded app.

Quote

The main reason I see for not using session_destroy is with larger applications where some module or plugin or whatever is storing data in the session also and you don't want to delete everything that you didn't set. Ideally you should only be deleting what your code set.


Half right. Not just ideally, but absolutely, you only delete what you set. It seems you dont fully understand session destroy. When you do a session destroy, it will ONLY and ALWAYS delete your OWN session, not anyone elses. When logging out of an app, there is ABSOLUTELY NO REASON to leave any session open for any reason.

I am thinking I may need to create a demo for people to really grasp this.

This post has been edited by benanamen: 31 March 2015 - 10:46 AM

Was This Post Helpful? 0
  • +
  • -

#12 ArtificialSoldier  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1789
  • View blog
  • Posts: 5,700
  • Joined: 15-January 14

Re: Destroying sessions on user logout.

Posted 31 March 2015 - 10:50 AM

Quote

We are still talking about a badly coded app.

OK, in that case it's not a terrible idea to destroy the session on the server.

Quote

When you do a session destroy, it will ONLY and ALWAYS delete your OWN session data, not anyone elses.

That's not true. When you have a bunch of different pieces of PHP code all using the session, and any one of them calls session_destroy, it most certainly does not delete only the data set by that piece of code. The entire session is destroyed. Multiple pieces of PHP running on the same server will use the same session if all they do is call session_start without changing the session name. If each script sets its own session name, yeah, it will only delete that session. If everything only uses session_start then session_destroy wipes out everyone else's data also.
Was This Post Helpful? 0
  • +
  • -

#13 benanamen  Icon User is offline

  • D.I.C Head

Reputation: 13
  • View blog
  • Posts: 119
  • Joined: 28-March 15

Re: Destroying sessions on user logout.

Posted 31 March 2015 - 11:17 AM

View PostArtificialSoldier, on 31 March 2015 - 10:50 AM, said:

Quote

We are still talking about a badly coded app.

OK, in that case it's not a terrible idea to destroy the session on the server.

Quote

When you do a session destroy, it will ONLY and ALWAYS delete your OWN session data, not anyone elses.

That's not true. When you have a bunch of different pieces of PHP code all using the session, and any one of them calls session_destroy, it most certainly does not delete only the data set by that piece of code. The entire session is destroyed. Multiple pieces of PHP running on the same server will use the same session if all they do is call session_start without changing the session name. If each script sets its own session name, yeah, it will only delete that session. If everything only uses session_start then session_destroy wipes out everyone else's data also.


I think we are not quite on the same page. Yes you are correct about multiple pieces of code and it will delete all of it....BUT....only all of it for the particular user logged in. If I log into the app and you log into the same app we are each assigned our OWN unique session ID. If I log out to a page that uses session destroy, it absolutely will not log you out or do anything whatsoever to your session variables. We both have our own session id. One does not mess with the other. If that were the case, every one of my apps would be constantly logging out all the other users as soon as one user logs out.


Even in a good coded app, it is still a security problem to not destroy the session on logout.

This post has been edited by benanamen: 31 March 2015 - 11:23 AM

Was This Post Helpful? 0
  • +
  • -

#14 benanamen  Icon User is offline

  • D.I.C Head

Reputation: 13
  • View blog
  • Posts: 119
  • Joined: 28-March 15

Re: Destroying sessions on user logout.

Posted 31 March 2015 - 11:33 AM

Atli just PM'd me and says you do understand, "Deletes Everything" refers to an individual session id. So we are good there. Not sure about you grasping the security end of it yet.
Was This Post Helpful? 0
  • +
  • -

#15 ArtificialSoldier  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1789
  • View blog
  • Posts: 5,700
  • Joined: 15-January 14

Re: Destroying sessions on user logout.

Posted 31 March 2015 - 11:35 AM

Quote

If I log into the app and you log into the same app we are each assigned our OWN unique session ID.

Yes, I understand that. I'm talking about multiple pieces of code all using the same session for the same user. It can be a problem if any of them decides to destroy the session. I'm having trouble remembering the details of this, but I've been burned by this once. I can't remember what specifically I was working on, but I was saving data in the session and some other code in some other part of the application decided to just destroy the entire session when they were done using it, which of course clobbered all of my data also. I can't remember if that was a version of Wordpress or what, I think it actually might have been CubeCart that I was working with. That other piece of code should not have been using session_destroy, it should have used unset on only the specific values that it was working with.
Was This Post Helpful? 0
  • +
  • -

  • (3 Pages)
  • +
  • 1
  • 2
  • 3