Session hijacking: Pros/Cons of a filter that suppresses Session IDs

I am trying to address session fixation/hijacking/sidejacking on an ATG/JBoss/Tomcat site. It seems that by far, the most commons recommendations are:

1. Grant a new session to the user when they log in. This prevents the attacker from being able to predict the session ID of the victim. I tried this approach first, but I fear it may not work in my case

2. Use a servlet filter to invalidate the session anytime a session ID (SID) is passed in the URL. The filter additionally prevents url rewriting for creating links w/ SIDs

What are the pros and cons of #2? Some that I've thought of:

Pros:

1. This seems like a broader protection than #1: #1 protects against malicious URLs being passed to the victim, #2 protects against any means of acquiring SIDs (insecure wireless net开发者_StackOverflow社区works, access to the machine, etc) - you can't just pass the SID you want to use a request parameter!

Cons:

1. Session management will be shot for users without cookies enabled.
2. Normal users will be logged out if they click a link w/ jsessionid specified, though I don't believe there will be any legitmate links like that in the system, due to the behavior of the filter.

2 is to stop Session Fixation.

You also need to take CSRF aka "Session Riding" into consideration. Here are methods of preventing CSRF.

Finaly don't forget the most overlooked OWASP, OWASP A9 - Insufficient Transport Layer Protection. This means that your Session ID must be transmitted over HTTPS at all times. If you don't then someone can use Firesheep to grab the account.

You could store a variable in the session that contains the user's IP, user agent, etc. or a hash of them and check it every request so that if it is hijacked the hijackers would have to fake those.

Not perfect but it helps.