7

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.

Community
  • 1
ccot
  • 197
  • 1
  • 6

4 Answers4

10

Whenever you are requesting a page with HTTP, everything is sent plaintext, that means the session cookie containing the id is sent plaintext as well (even for image requests). That makes it an easy target for MITM attacks. You can configure the cookie to be sent to HTTPS pages only, but of course you will loose the session then on HTTP pages.

The best way to deal with this problem is, to make the whole site HTTPS only, you can avoid a lot of troubles this way. As long as your site doesn't have very high traffic, it should be no problem for todays servers.

If you really have to switch between HTTP and HTTPS pages, you could separate the two concerns of maintaining the session and authentication. You can add a second cookie only for authentication and restrict it to HTTPS pages only. The session cookie can then be used for both HTTP and HTTPS requests. I wrote an example of how this could be implemented (it's written in PHP, but the idea can be implemented in other environments as well).

martinstoeckli
  • 5,149
  • 2
  • 27
  • 32
  • thx for the help:) the web app is not yet in production mode yet, and thus i cannot anticipate how much traffic it will have. That's why i did not do the whole site HTTPS. Concerning your example about seperate cookies, it is actually a very good idea! But do i need it if switching to HTTPS happens only "Once" (only when user wants to login. I only have one https page) ? – ccot Apr 27 '12 at 21:31
  • 1
    @shadesco - Yes, the problem is, that you have to send the session id for every following request, so the server can recognize the user. When you send the id with HTTP, it can be eavesdropped and the attacker can use this id for his own requests. The server would recognize the attacker as the logged in user and would grant him the same priviledges. – martinstoeckli Apr 27 '12 at 21:45
  • The problem with HTTPS performance is not exactly and only related to the amount of traffic the site has, but rather on the type of website: because HTTPS's overhead is mainly due to the initial handshakes, a site serving small amounts of static data to the users several tines will be more impacted by it than a website that serves a huge amount of dynamic data. – user1301428 Apr 28 '12 at 06:37
4

Yes. The session can be hijacked. Your approach is not secure. The only way to provide reasonable security is to use HTTPS for everything.

You are sending the session ID over HTTP, which means it is going in the clear, which means it can be intercepted. Once it is intercepted, the attacker has everything needed to take control of the user's account (including, possibly, the parts of the application you've relegated to HTTPS).

I encourage you to read up on Firesheep, which exploits exactly this sort of architecture. Sites need to use HTTPS for everything, if they want to be secure against eavesdropping and man-in-the-middle attacks (e.g., if they want to be secure for users who are connecting over open Wifi).

See the following questions on this site: What are the pros and cons of site wide SSL (https)?, When are HTTP session cookies at risk over Wi-Fi?, and What sites are still vulnerable to FireSheep?.

Here's what I suggest for your site:

  • Use SSL sitewide: i.e., use only HTTPS, not HTTP. Don't use HTTP for anything; use only HTTPS. Enable HTTP Strict Transport Security. Set the secure flag on all cookies.

  • Think carefully about how you will authenticate users.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • logically speaking, i am for using HTTPS only for the whole site. But why do famous large sites use it for login only? or is it just a myth the performance degrade , from your experience? – ccot Apr 29 '12 at 01:00
  • @shadesco, I'm very confused. In your question, you say "the user is redirected to the application page but using HTTP" and that your app "makes HTTP calls" and "he first landing page is HTTP", and you talk about "returning to HTTP". I don't understand how you can say you are "using HTTPS only". This is all terribly confusing for me. I think you'll need to be more precise, if you want useful feedback. Note: when I say HTTPS only, I really mean HTTPS only -- no HTTP. – D.W. Apr 29 '12 at 01:27
  • @shadesco, as far as your question about why some famous large sites use HTTPS for login only, this is all covered in the links that I gave. See, e.g., [What are the pros and cons of site wide SSL (https)?](http://security.stackexchange.com/q/258/971), which explains that HTTPS-only poses some problems, most notably with respect to ads, third-party content, and CDNs, but also modest performance challenges for very-high-volume sites. Did you read what I wrote? Did you read the links? Please read before asking further. – D.W. Apr 29 '12 at 01:30
  • when you go to the application, its HTTP. You can use basic functionalities (like a demo). When you want to start using your own data and other functionalities, you need to login. the login PAGE is HTTPS. when authenticated, the app redirects you to main page which is HTTP only. Yes i did read what you wrote and the links, thanks for providing them. I just asked you for your "personal" experience with HTTPS – ccot Apr 29 '12 at 07:15
2

One of the biggest attack vectors when it comes to HTTPS relies on tricking the user. It is always the responsibility of the user to check that HTTPS is used when they expect it. Only the users can check whether they haven't been downgraded to plain HTTP (and that the certificates are valid).

The "j2ee CONFIDENTIAL security constraint" is barely useful in that respect. Yes, it will force a redirection, but this redirection could be handled by an active MITM instead. Make sure the links the the HTTPS sections use https:// (more details here).

As @martinstoeckli said, if you can, use HTTPS everywhere. Failing that, make sure that wherever you've judged the HTTPS was more importantly required, the users should expect to use HTTPS (and will move away if those pages are only using plain HTTP).

There are very few technical solutions to making sure the user makes the right verifications. One of them is for the users to use a browser that support HTTP Strict Transport Security, although they would (a) need to have such a browser and (b) expect HTTPS the first time (this is better if there is a pre-loaded list of HSTS-enabled sites).

Community
  • 1
Bruno
  • 10,765
  • 1
  • 39
  • 59
  • thx for explaining about how to force HTTPS, much appreciated! the thing is the web app is not yet in production mode, and i don't know what level of traffic it will have that's why i am not making the whole site HTTPS, because i heard it degrades performance. – ccot Apr 27 '12 at 21:43
-1

These are a typical kind of questions where the answer doesn't matter.

If the answer is Yes it can be hijacked, you know you have to take counter measures.

If the answer is No ... all that is being said is: "I am not aware of any attack vector", but you can never be 100% sure and still you have to take counter measures.

So whatever the answer is, take counter measures or don't redirect to http.

You can never be sure something is 'fail-safe', you can only prove something failed.

jippie
  • 790
  • 1
  • 4
  • 9
  • So when somebody can prove that it fails, then shadesco would know that he should use another method, and that was his question, wasn't it? But you are right that it is probably not possible to prove the opposite. – martinstoeckli Apr 27 '12 at 20:15