What is session hijacking in java ?

Question

Hi we want to know the term session hijacking in java language.

Senthilkumar · Answer

Hi Abhishek 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. Secure and HTTPOnly are two options available to all HTTP cookies. A secure cookie will only be sent through HTTPS protocol. An HTTPOnly cookie prevents javascript to retrieve and manipulate it. These two options when applied to HTTP session id cookies add more defense on the secrecy of the session id. Again no standard way to add these two options to Java EE web applications; you need to consult your application server documentation. Like all application features after you implement these tips you must test the application. Firebug is a valuable tool to verify the session ids from HTTP requests and responses. Burp Suite can record and modify HTTP traffic and simulate various attack. For more info: http://www.imperva.com/resources/glossary/session_hijacking.html