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 ?

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

See also: OWASP -- Session Fixation

Answer 5

My explanation is specific to PHP but it is imaginable that your Java application has a similar behavior. It is easily tested though.

TLDR: Yes, in PHP and Firefox it is possible to add a second session cookie which, due to the order in the header, is preferred over the original one. Also Yes, if there is other functionality which allows to set session IDs on the server. This depends on the application specific functionality.

Full explanation

Depends on what other functionality you have on your website to manipulate sessions. In some rare occasions, the application allows a user to set a session via a HTTP request. For example, via a GET parameter.

I believe you want to know if it is possible to fixate a session ID if the original session ID is set in a cookie with the HttpOnly flag. Therefore, I did a small test on a PHP application I was conducting a pentest on. Surprisingly, you can set a new PHPSESSID via a JavaScript injected as XSS. If there already was an existing PHPSESSID cookie with the HttpOnly flag, it simply puts this one next to the other one. In my case, in Firefox, it sent the following Cookies to the server after my attempt to set PHPSESSID via document.cookie = "PHPSESSID=FIXATEDSESSIONID":

Cookie: PHPSESSID=FIXATEDSESSIONID; __utma=139474299.465096418.1547461023.1548839033.1548851774.5; __utmz=139474299.1547461023.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); acceptCookies=true; 

So there are now two session IDs in the request. In my setup, with PHP 5.6.25, the server takes the first cookie to bind a session. So in the case with Firefox and PHP 5.6.25, I was able to fixate my session ID (FIXATEDSESSIONID) via a JavaScript. The original session ID is still in the request but it is ignored by the server. Note that FIXATEDSESSIONID is literally the session ID I injected. So it was not necessary to get a legitimate session ID from the PHP server.