The first things you should do is to make sure you limit the chances an
attacker has at getting a valid session cookie. A short list includes:
- generating sufficiently random tokens
- having a short session timeout
- destroying a token upon user logout
- eliminating cross site scripting issues from your site
- Using the HttpOnly flag on your cookie -
http://msdn.microsoft.com/workshop/author/dhtml/httponly_cookies.asp
...
There are a couple of things you can think about using to make cookie
theft a bit more difficult. (These ideas are really Jeremiah Grossman's
not mine)
- Hash the token using the first octet of the IP address. I don't
recall a valid user hoping across a Class A, though it could happen.
- Hash the token using the User-Agent string from the browser.
These two things can raise the bar for any would be cookie thief. If
you employed both of these then the cookie thief would need to know
that you where doing, then get the first octet of the victims IP and
get the full user-agent string. This is not impossible of course but it
raises the bar considerably.
Hope that helps. I know others will have good ideas as well.
Oh one more thing, I seem to recall IE will re-negotiate SSL sessions
after a certain period of time so you can't really use SSL sessions.
On Wednesday, July 23, 2003, at 10:33 PM, Phil Cox wrote:
> All,
>
> I have a question on how people are handling cookie stealing and
> session
> segregation. For example, it is possible to use session cookie
> information
> on multiple systems for most (all?) web applications I know of. Here
> is a
> scenario:
>
> When a user logs in he is assigned a BLAH_SESSIONID cookie which
> serves as
> an authorization mechanism in the application. The application does
> not
> associate the cookie to any session-specific information (e.g., source
> IP
> address), so another user can also use the BLAH_SESSIONID cookie to
> access
> the same information (over a different TCP/IP session) that the
> legitimate
> user can. If an attacker obtains, or guesses a valid BLAH_SESSIONID
> cookie
> for an active session, he can use it without the user's knowledge. For
> example, I was able to execute the following command using an
> BLAH_SESSIONID
> that was obtained from another session: Command on Linux box:
>
> # curl -b "BLAH_SESSIONID=0000FDHTNLVY5WX"
> https://somesite.com/App/Function?
>
> Returns the page: (some portion of the returned page)
>
> Historically I have believed that having the application associate the
> BLAH_SESSIONID session cookie and its associated privileges with a
> specific
> SSL session or source IP address would prevent this session stealing.
> But
> recently I have been told that this solution does not work because of
> the
> dynamic IP nature of MANY ISP's and the disassociation of SSL/HTTP. I
> would
> like to know what others are doing to solve this problem, or if they
> are
> just not solving it at all.
>
> Thoughts and comments are appreciated...
>
> Phil
>
>
>
---
Bill Pennington, CISSP, CCNA
Chief Technology Officer
WhiteHat Security Inc.
http://www.whitehatsec.com
Received on Jul 24 2003
Intro
