The information in session state is very secure, because it is stored exclusively on the server. However,the cookie with the session ID can easily become compromised. This means an eavesdropper could steal the cookie and assume the session on another computer.
Several workarounds address this problem. One common approach is to use a custom session module that checks for changes in the client’s IP address. However, the only truly secure approach is to restrict session cookies to portions of your website that use SSL.
That way, the session cookie is encrypted and useless on other computers. If you choose to use this approach, it also makes sense to mark the session cookie as a secure cookie so that it will be sent only over SSL connections.
That prevents the user from changing the URL from https:// to http://, which would send the cookie without SSL. Here’s the code you need:
Request.Cookies["MySessionId"].Secure = true;
Typically, you’ll use this code immediately after the user is authenticated. Make sure there is at least one piece of information in session state so the session isn’t abandoned (and then re-created later). Another related security risk exists with cookieless sessions. Even if the session ID is encrypted, a clever user could use a social engineering attack to trick a user into joining a specific session.
All the malicious user needs to do is feed the user a URL with a valid session ID. When the user clicks the link, he joins that session. Although the session ID is protected from this point onward, the attacker now knows what session ID is in use and can hijack the session at a later time.
Taking certain steps can reduce the likelihood of this attack. First, when using cookieless sessions, always set regenerateExpiredSessionId to true. This prevents the attacker from supplying a session ID that’s expired. Next, explicitly abandon the current session before logging in a new user.
Quoted.