11

I have a Java application running on Tomcat 6.0.29, with Apache 2.2.3 in front. The login page uses HTTPS, while most pages use HTTP.

If a user tries to access a page (HTTP) that is login protected, he gets redirected to the login page (HTTPS), logs in, then gets redirected back to the originally requested page. This works great, as the JSESSIONID cookie is set as non-secure, and used for both HTTP and HTTPS.

However, if the user starts at the login page (HTTPS), the JSESSIONID cookie is set as Secure, and thus the session is not available after login when redirecting to pages under HTTP, forcing a new session and redirect to login page again. This time it works though, because this time the JSESSIONID cookie is set as non-secure.

How can I avoid that users have to log in twice when they hit the login page first?

rlovtang
  • 4,860
  • 2
  • 30
  • 30
  • possible duplicate of [HTTPS login not saving the JSESSIONID in a cookie](http://stackoverflow.com/questions/3963958/https-login-not-saving-the-jsessionid-in-a-cookie) – leonbloy Jan 08 '11 at 18:41
  • 1
    Thanks @leonbloy. It's very related yes (except I'm in control of the login page myself). The solution to add a non secure cookie in a filter could do. But it feels like a hack, there must be a better way.. – rlovtang Jan 08 '11 at 18:49
  • The easiest solution would probably be to do as 98% of the sites out there, let the login page be insecure, while posting to a secure URL. But that's a security issue as a man in the middle could change the post URL and collect usernames/passwords – rlovtang Jan 08 '11 at 18:52
  • 2
    You could do the sensible thing and have the whole of the site requiring authentication behind https. If you're sending auth cookies and presumably restricted data unsecured, then there was no point having a protected login form to start with. – OrangeDog Jan 08 '11 at 22:29
  • @OrangeDog The the reason to protect the login is to avoid sending usernames and passwords in clear text. The rest of the application does not need HTTPS – rlovtang Jan 09 '11 at 09:18
  • @rlovtang - Even then, your users are still vulnerable to session hijacking. – OrangeDog Jan 09 '11 at 17:40
  • 1
    @OrangeDog I know, but that's not a big threat to this particular application. There's a few threads on SO on pros and cons of running pure HTTPS. I've read them, and my conclusion is that I don't want to. Like most sites out there e.g. stackoverflow.com – rlovtang Jan 09 '11 at 17:55

1 Answers1

7

(Update: for clarity) Starting with the login Http get/post use https and use https through out the user's logged in session.

Use Http only when there is no logged in user.

There is a reason that cookies are not allow to cross protocol boundaries - it is an attack vector! (* see update below)

How to do this very bad idea

If you really insist, encode the jsessionId in the redirect to the http url ( or always encode the jsession id in the url). When Tomcat gets the http redirect, tomcat should find the session and continue.

Why you shouldn't do this

Seriously, any site that mixes https and http content on the same page is just opening themselves to all sorts of fun (and easy) attacks.

Going from https to keep the login "secure" is pointless if the rest of the session is in cleartext. So what that the username/password (probably just the password) is protected?

Using the ever-popular man-in-the-middle attack, the attacker just copies the session id and uses that to have fun. Since most sites don't expire sessions that stay active, the MIM effectively has full access as if they had the password.

If you think https is expensive in terms of performance look here, or just search. Easiest way to improve https performance to acceptable is to make sure the server is setting keep-alive on the connection.

Pat
  • 5,761
  • 5
  • 34
  • 50
  • So what you are saying is that every site that has some form of login, should use HTTPS for all pages, and sites that use HTTP should never use sessions. – rlovtang Jan 10 '11 at 11:34
  • No. What I am saying is that once a user logs in to a site, *all* traffic to/from that site should be via https until the user logs out. I just edited the original answer. – Pat Jan 10 '11 at 21:39
  • 1
    Twitter, facebook, stackoverflow etc seems to disagree – rlovtang Jan 10 '11 at 22:47
  • 1
    Google and banks do agree. Hey but go ahead do it and encode the url with the sessionId. If your service doesn't have assets where the risk is "that" great, whatever. Just realize that Session Hijacking is a certainty. This is why the wall of sheep ( http://www.wallofsheep.com/ ) exists. – Pat Jan 10 '11 at 23:52
  • Thanks @Pat, I'm aware of the risk. Google search uses HTTP even though you're logged in btw. But I suspect you refer to Google products like Gmail and Calendar. They, as well as banks, displays highly sensitive data. Banks even protect the login with a token provided by a calculator or sent by SMS. Each application needs to choose its level of security. My application is read-only and displays data that could as well be public, but is limited to a group of people for now. If someone hijacks the session, they'll be able to see where the trains are and how delayed they are. No harm. – rlovtang Jan 11 '11 at 08:28
  • "Starting with the login Http": the login page should also use HTTPS – rlovtang Jan 11 '11 at 08:31
  • Google search uses https://encrypted.google.com/ Notice also that when you hover over the "cached" link in the search results the domain the cached content is hosted from "webcache.googleusercontent.com" to avoid this attack. – Pat Jan 11 '11 at 16:51
  • @rlovtang - well if the app is read-only, alternatives are: 1) use openid so user doesn't have to create a new account; 2) just not use http until data becomes more critical; – Pat Jan 11 '11 at 16:52
  • @Pat this is corporate users with preexisting usernames/passwords. No creation of accounts is done in this application – rlovtang Jan 11 '11 at 20:59
  • @Pat, one problem with HTTPS only site is if you show external images. Most of these are only served on HTTP and the browsers complain about mixed content. – ivant May 08 '13 at 15:28