views:

71

answers:

1

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.

A: 

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).

Bruno
Thanks Bruno. I'll have to have a think about this one. I want a secure, robust site. But I also want a customer to be able to move around the site freely.
Sadly, you can't avoid user education when it comes to security. The trick is the get it to a minimal level. Your users will have to expect they're entering or leaving somewhere secure, just like everyone nowadays checks their browsers for online-banking.If you're users aren't expected to check, they can be tricked. An attacker could very well catch all plain HTTP requests and handle them directly, without ever sending them to the HTTPS page (or perhaps relay it as he wishes and alter the content).
Bruno
I've been reading around Tomcat security/techniques a lot. My intention at the moment is to 1) Configure container managed authentication (declarative, form-based, SSL). 2) Use a filter to check IP/user-agent/ssl is unchanged in each request. 3) Consider disabling URL rewriting (mainly because of rumours that it impacts google SEO).thanks again.Steven.
Regarding point 2), you might find reading about cross-site request forgeries (CSRF) interesting. It's a slightly different problem, but source IP protection isn't always a good thing, in particular because some user-agents may be behind a pool of proxy servers with different IP addresses.
Bruno