Session fixation attack, cookie based sessions over https

Question

A third party security consultant did a Penetration test few of our webapps. One of the findings was a potential session fixation vulnerability.

We have several webapps all Java with single sign on provided by JASIG CAS. To briefly summarize CAS workflow -- when a new request comes to webapp(service in CAS terminology) it redirects to preset CAS url. If the user is not already authenticated, it presents a login form and upon successful redirects the browser back to the service with a token. In case the user is already authenticated, it immediately redirects back to service with a token.

The aforementioned vulnerability stems from the fact that the service in question sets the session cookie (named JSESSIONID) when it is redirecting to CAS ie before authentication AND continues to use it after redirect. The claim is since same session id is used before and after authentication it is open to session fixation types of attack.

Given that all services and CAS are working exclusively over https and session cookie is secure, http only and generated at server, is there any way session fixation may be a threat here ?

Ask the person/company providing the Penetration test report to provide a proof of concept for the vulnerability in question, also check your SSL configuration at each point and ensure PFS is at least supported on all modern browsers (Use ssllabs.com for example) . — Oneiroi, Jun 27 '17 at 11:21
@Oneiroi, yes that can be done, changing the sessionid is not a big problem in itself either. I wanted some insights from community to better my understanding. — mzzzzb, Jun 27 '17 at 13:37

score 1 · Answer 1 · answered Jun 27 '17 at 10:28

1

For every session fixation vulnerability the attacker must know the session identifier. There two ways to ways to obtain it – by stealing it from victim’s PC and through brute-force attack.

Httponly attribute protects your cookie against XSS attacks using browser same-origin policy, but there are many other ways to access victim’s PC and steal the cookie, including vulnerability exploitation in victim's browser.

Unfortunately I’m not familiar with CAS and do now know for how long the session id is kept unchanged. If your server keeps using the same session id for a significant amount of time, then it is possible to brute-force/predict it. This is where the session fixation becomes dangerous.

My advice is to generate new session token every 15-20 minutes for active sessions as well. This way it will be extremely hard to brute-forced it and your application will be protected against session fixation attacks.

answered Jun 27 '17 at 10:28

Valery Marchuk

546
2
6

I agree with @valery-marchuk. It is interesting that your application uses the same JSESSIONID both before and after authentication. By this, I assume that you mean the "same value for the cookie". This *is not a problem ONLY if* there is a separate mechanism to identify the state of the session (authenticated or not). – Sas3 Jun 27 '17 at 10:41
CAS flow is somewhat like sign in with Google, difference being CAS is something we host ourselves. The sessionid in question is set by individual webapp and not by CAS. If we remove CAS from the picture and assume the webapp itself handles authentication itself and all other things remaining as is, then would it be an issue that session cookie is unchanged before and after authentication ? – mzzzzb Jun 27 '17 at 13:41
mzzzzb, yes, it would be an issue. If the token is used to authenticate/validate the user, then it can be used by the attacker to gain access to victim’s session. – Valery Marchuk Jun 27 '17 at 13:45
yes, but how would someone be able to get hold of the session cookie – mzzzzb Jun 28 '17 at 05:31
The simpliest answer is by brute-forcing it. If you do not change it, I have unlimitted time for the brute-force attack. – Valery Marchuk Jun 28 '17 at 10:11
1

it expires on browser close. I would not worry about bruteforce, there is sufficient entropy -- 64 chars alphanum and few special chars – mzzzzb Jun 28 '17 at 13:35

score 0 · Answer 2 · answered Aug 05 '18 at 21:57

From what I can see, CAS is a form of OAuth2 authentication, although they don't use that term on their system.

To make OAuth2 secure, the service using it has to have a set of keys (it's more like having a secret login and password.) Without such keys, it would be very easy to send the user directly to the CAS server with an ID so the attacker knows exactly what ID you're going to use.

+------------------+                   +----------------------+
|                  |                   |                      |
|  Your Server     +-------+---------->|  CAS Server          |
|                  |       |           |                      |
+------------------+       |           +--------+-------------+
                           |                    |
+------------------+       |                    |
|                  |       |                    |
|  Hacker Server   +-------+                    |
|                  |                            v
+---------+--------+                   +----------------------+
          .                            |                      |
          +...........................>|  Back to Your Server |
                                       |                      |
                                       +----------------------+

Without some secrets from your computer, we have a very simple way of knowing what the session identifier as a hacker. We just generate said ID and send you to the CAS Server. Wait a little and then access the concerned server.

I would imagine that CAS has the necessary secrets so this wouldn't work.

Now, if I can create an XSS attack which sets a cookie with the session ID then I can also gain the necessary knowledge to connect to the server once the user is logged in.

With the XSS they would likely be exploiting an issue on your systems. So the hacker has a link to your server which does something wrong and executes the hacker's code (JavaScript or a meta tag). That code sets the session ID or checks the existing session ID and POSTs it to one of the hacker's computer.

+------------------+                   +----------------------+
|                  |                   |                      |
|  Your Server     +------------------>|  CAS Server          |
|                  |                   |                      |
+------------+-----+                   +--------+-------------+
         ^   |                                  |
         |   |                                  |
         |   v                                  v
+--------+---------+                   +----------------------+
|                  |                   |                      |
|  Hacker Server   +..................>|  Back to Your Server |
|                  |                   |                      |
+------------------+                   +----------------------+

In this case, since the session ID won't change, they will have access to your server for 15 to 20 minutes once the user is logged in. An XSS attack is rather easy to avoid, but I've heard of many such attacks (I worked on Drupal for a while and discovered quite a few from programmers who don't think out of the box and use possibly tainted data as is.)

An example of such is to hit a 404 page using code in the URI:

http://example.com/<script>document.cookie = "JSESSIONID=123";</script>

A programmer who creates a 404 page and shows the <script> tag as is (i.e. without replacing the < with < and > with >) allows for a cross-site attack as the rogue JavaScript will be executed on your site.

Note that with a Man In The Middle (MITM) attack, you don't even need an XSS or a bad OAuth2 like implementation. But it's harder to execute an MITM and in most cases requires a public place so people at work are less likely to have a hacker colleague who knows how to be an MITM.

symcbean · Answer 3 · 2018-08-05T23:42:48.147

Either you've not understood the security consultant or they don't know what they are talking about.

You need to dig a bit deeper to find out the truth.

Asking the security consultant to demonstrate the vulnerability might prove the former but a failure does not prove the latter.

Session cookies must be set with the secure flag. If the session Id is not resolved when presented by a client, the server must generate a new session id. It is good practice to generate a new session id (and set this at the client) when the authentication state changes (in your scenario, when your app validates the token with the authentication service and when the user logs out - after destroying the data referenced by the old id).

Assuming that your cookies are set with the secure flag....

For your implementation to be vulnerable, it must be accepting a session id relating to a non-existent session. If that is not the case, then the consultant is wrong, however you should still apply the third recommendation above.

Consider: you are browsing http://example.com. An attacker can inject a header in a server response setting the session id to a known value. If you subsequently login at https://example.com your browser will send the session id set by the attacker (the SSO part is irrelevant). If your server did not change the session id when it was first presented (and therefore referencing null session data) it's now the one chosen by your attacker.

Using hsts would help, but the important stuff is the three steps above.

score 0 · Answer 4 · answered Sep 18 '18 at 16:15

I assume that your web application does not generate a new session ID after the client is redirected back to your application in the CAS workflow. Therefore an attacker can obtain a valid session ID without login and try to trick another client into still using that after a successful login.

Best practice is to generate a new session ID after each login.

Session fixation attack, cookie based sessions over https

5 Answers5