How to stop session hijacking programmatically ?

HTTP is a stateless protocol. In order to track users, web applications rely on server side sessions. Two basic ways to link clients(usually browsers) to sessions are through URL rewriting and HTTP cookie. Both ways allow browsers send HTTP session id to server. URL rewriting automatically changes all URLs and sends session id as an HTTP request parameter. HTTP cookie allows server send the session id via a cookie to client when session begins, and client keeps the cookie in memory and submits the cookie with every subsequent request. Session id is very critical to web applications. A session is associated with a logged-in user and all his/her security privileges and personal information. If an attacker gets hold of a valid session id, he can impersonate the victim and conduct damages. This is called session hijacking. Some general tips to protect sessions are: Tip #1. Turn off URL rewriting. As stated above, URL rewriting appends session id to every URL, which will be displayed in browser window, kept in browser history and can be captured by many intermediary nodes on the Internet to the application servers. Furthermore, many web sites link to third party sites for images or javascripts, and those sites could capture session id through Referrer HTTP header. So whenever possible, turn URL rewriting off. Unfortunately, Java EE Servlet specification doesn't define a unified way to control URL rewriting; you need to check your application server documentation to find a way to do it. Tip #2. Start a new session after user logs in. The ideal way for scalability and performance is to avoid using session before user logs in. If you do need to use sessions for anonymous users, after successful authentication, make sure you invalidate the old session and create a new session. Tip #3. Use HTTPS protocol for at least login process and all subsequent requests. If you follow tip #1 and #2, after login, server will send session id as a cookie to browser, and all subsequent requests from browser will contain that cookie. All these traffic must be encrypted via SSL/TLS so that no third party can intercept the session id. If you can't follow tip #2 for any reason, then you must force SSL/TLS for all your web site traffic. Tip #4. Implement a servlet filter to ensure all access for sensitive sections have valid session and user privileges. This catches any potential break-in and redirects those requests to safe public pages. Tip #5. Mark session id cookie secure and HTTPOnly. read less

First of all let us be clear about what is Session Hijacking, session hijacking is exploitation of a valid computer session to gain unauthorized access to information or services in a computer system. Talking about HTTP or HTTPS means we are targeting HTTP protocol only. But session can be used with protocols other than HTTP. Thus we need to have a generic answer. The basic of this process is encrypting the data at the sender end with the public key shared by the receiver itself, which is actually done when using HTTPS. Thus as mentioned in the query that how can we prevent session hijacking programmatically, so my solution would be that if you are working with HTTP protocol you can go for HTTPS or if you are using some other protocol you can go for secured version of the same like we do between HTTP and HTTPS. If there is no such then you can use ant public key encryption technique available in the market. read less

Encrypting the session value will have zero effect. The session cookie is already an arbitrary value, encrypting it will just generate another arbitrary value that can be sniffed. The only real solution is HTTPS. If you don't want to do SSL on your whole site (maybe you have performance concerns), you might be able to get away with only SSL protecting the sensitive areas. To do that, first make sure your login page is HTTPS. When a user logs in, set a secure cookie (meaning the browser will only transmit it over an SSL link) in addition to the regular session cookie. Then, when a user visits one of your "sensitive" areas, redirect them to HTTPS, and check for the presence of that secure cookie. A real user will have it, a session hijacker will not. read less

the best answer to use SSL/HTTPS encryption for the entire web site, and you have the best guarantee that no man in the middle attacks will be able to sniff an existing client session cookie And perhaps second best to use some sort of encryption on the session value itself that is stored in your session cookie read less

76 down vote favorite 40 Specifically this is regarding when using a client session cookie to identify a session on the server. Is the best answer to use SSL/HTTPS encryption for the entire web site, and you have the best guarantee that no man in the middle attacks will be able to sniff an existing client session cookie? And perhaps second best to use some sort of encryption on the session value itself that is stored in your session cookie? If a malicious user has physical access to a machine, they can still look at the filesystem to retrieve a valid session cookie and use that to hijack a session? read less

The only real solution is HTTPS. If you don't want to do SSL on your whole site (maybe you have performance concerns), you might be able to get away with only SSL protecting the sensitive areas. To do that, first make sure your login page is HTTPS. When a user logs in, set a secure cookie (meaning the browser will only transmit it over an SSL link) in addition to the regular session cookie. Then, when a user visits one of your "sensitive" areas, redirect them to HTTPS, and check for the presence of that secure cookie. A real user will have it, a session hijacker will not. read less