What is session hijacking in java ?

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:

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.

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.

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.

This catches any potential break-in and redirects those requests to safe public pages.

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