CODEWITHSUNDEEP
urlsessiontomcathttpsurl-rewriting
user373009
user373009

Reputation: 33

Tomcat session management - url rewrite and switching from http to https

I'm an old hand at C but a raw newbie at Java/Tomcat.

I'm fine with Tomcat session management in http alone. Its when I've come to look at switching to https that I've had problems.

I gather for Tomcat that you have to start with an http session if you want to maintain a session as you switch from http to https and back to http. This works fine for me when the browser is enabled for cookies.

But when the browser is disabled for cookies (and URL rewriting is being used) then switching http to https or back again causes a fresh session to be started each time. I'm assuming this is a security thing.

Q1 - Is it possible/desirable to maintain a session between http and https using URL rewriting?

Q2 - If it isnt possible then what do e-commerce developers do about non-cookie users?

I dont want to prevent non-cookie people using my site. I do want some flexibility switching between http and https.

thanks for any help, Steven.

Upvotes: 2

Views: 2834

Answers (1)

Bruno
Bruno

Reputation: 122729

It doesn't seem desirable to maintain session between HTTP and HTTPS using the same cookie or URL token.

Imagine the case where you're user is logged on, with a given cookie (or URL token) passed back and forth for every request/response in an e-commerce website. If someone in the middle is able to read that cookie, he can then log on to the HTTP or HTTPS variant of the site with it. Even if whatever the legitimate user is then doing is over HTTPS, the attacker will still be able to access that session (because he too will have the legitimate cookie). He could see pages like the cart, the payment method, perhaps change the delivery address.

It makes sense to pass some form of token between the HTTP session and the HTTPS session (if you're using sessions), but treating them as one and the same would cause some vulnerability. Creating a one-off token in the query parameter just the transition could be a solution. You should however treat them as two separate authenticated sessions.

This vulnerability can happen sometimes with websites that use mixed HTTP and HTTPS content (certain browsers such as Firefox will give you a warning when that happens, although most people tend to disable it the first time it pops up). You could have your HTTPS session cookie for the main page, but that page contains images for the company logo, over plain HTTP. Unfortunately, the browser would send the cookie for both (so the attacker would be able the cookie then). I've seen it happen, even if the image in question wasn't even there (the browser would send the request with the cookie to the server, even if it returned a 404 not found).

Upvotes: 1

Related Questions