I am developing a web app, which makes HTTP calls as long as the user is not logged in.
Once the user clicks the login button, he is sent to a "login page" that is HTTPS.
The login makes an Ajax call to a servlet, where some specific attributes are added to the session.
Then, to solve the problem of "session fixation", the current session is invalidated and a new session is created.
After login, the user is redirected to the application page but using HTTP.
Now in order not to lose the session attributes (between HTTPS and HTTP) I overrode the default Glassfish mechanism by caching the JSESSIONID cookie and sending it in response: (this is a j2ee application)
Cookie cookie = new Cookie("JSESSIONID", request.getSession().getId()); cookie.setMaxAge(-1); cookie.setSecure(false); cookie.setPath(request.getContextPath()); response.addCookie(cookie);
It works fine, but I have been reading on Stack Overflow, IT Security and generally online that the session could still be hijacked. For example this answer mentions that is a very bad idea, and that a man in the middle can hijack it.
I am no security expert, but I would like your feedback on the following mechanism which I built:
- When typing web app URL, the first landing page is HTTP. All the mechanisms are HTTP.
- When the user decides to "login", he is redirected to a page, and that "landing" page is HTTPS (enforced through j2ee CONFIDENTIAL security constraint)
- On servlet, session fixation is taken care of by invalidating session and creating a new one. Then session attributes are added.
- In order not to lose session attributes while returning to HTTP, a cookie is manually overridden with the same "Session ID", and set to "non secure".
- All app requests are HTTP again.
Is this still an easy target for session hijacking / MITM / or any other security flaws?
I would appreciate feedback as I am not very experienced with security details.