Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | RE: Cookie not expiring... |
|---|---|
| Date: | Wed, 17 Aug 2005 09:02:43 -0500 |
This is simply not the case. I have personally seen this problem on assessments in the past. There are a slew of sites out there that will "logout" a user session by simply removing/invalidating the cookies on the users system. This prevents the legitimate user from continuing to use the session, but has no effect on the session itself. If an attacker has managed to snoop the cookie information, he can hijack the user's session and continue on as if no logout had occurred (from the server's perspective, it hasn't). In order to properly/securely logout a user, you MUST destroy the server-side session information. Once you do that, destroying the client-side cookie becomes almost moot -- even with the sessionid from the cookie, no valid information can be gained (the session that the id points to is dead/useless). Dan Simon C|EH, SCJD, SCJP Remington Associates, Ltd. -----Original Message----- From: dharmeshmm@mastek.com [mailto:dharmeshmm@mastek.com] Sent: Wednesday, August 17, 2005 8:25 AM To: webappsec@securityfocus.com Subject: Re: Cookie not expiring... Hi All, I think the case is only with Cookieless sessions. "Session ID values used in cookieless sessions are recycled by default. That is, if a request is made with a session ID that has expired, a new session is started using the System.Web.SessionState.HttpSessionState.SessionID supplied with the request. This behavior can result in the unwanted sharing of session data when a link that contains a cookieless System.Web.SessionState.HttpSessionState.SessionID is shared with multiple browsers perhaps through a search engine or other means. You can reduce the possibility of session data being shared by multiple clients by disabling the recycling of session identifiers. To do this, set the regenerateExpiredSessionId attribute of the <sessionState> configuration element to true. This will result in a new session id being generated when a cookieless session request is made with an expired session id." But the most important thing that was missed is "If the request made with the expired session id is made using the HTTP POST method, then any posted data will be lost when regenerateExpiredSessionId is true, as ASP.NET performs a redirect to ensure that the browser has the new session identifier in the URL." And in .NET, you call the System.Web.SessionState.HttpSessionStateProvider.Abandon method when a user logs out. This reduces the potential for an unwanted source using the unique identifier stored in the URL to retrieve private data stored in the session for a user. Regards, Dharmesh Mehta Technology Cell, Mastek Ltd.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Cookie not expiring..., dharmeshmm |
|---|---|
| Next by Date: | Re: Re[2]: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection), Chuck |
| Previous by Thread: | Re: Cookie not expiring..., dharmeshmm |
| Next by Thread: | Windows 2003 Server Hardening, Joe Osborn |
| Indexes: | [Date] [Thread] [Top] [All Lists] |