How to avoid Session Fixation? 

How to avoid Session Fixation? 

  

Hi everyone,
 
We had a security auditory and one of the issues detected was Session Fixation.  Anyone knows how to solve this issue?
 
In a shell this is the behavior we want to avoid:

 

  1. You open a browser in the login page of Enterprise Manager in two machines
  2. You copy the ASP.NET_SessionId cookie from machine A to machine B
  3. You logon in B
  4. You refresh the browser in A and you are logged in with the credentials you entered in B 

 

Hi Luis,

Thanks for the question. As you know, the Agile Platform sessions are managed by the ASP.Net session controller, so to look into it you'd probably want to check out some articles on addressing Session Fixation in .Net.

http://stackoverflow.com/questions/2402312/session-fixation-in-asp-net

http://discuss.joelonsoftware.com/default.asp?dotnet.12.484800.5

Here are two articles to get you started. However, since I never heard about anyone talking about addressing that, I would recommend a small check with our Technical Support, since they can better recommend how to approach that problem in your server environment.

Has anyone else ever bumped into this, and tried to address it?

Regards,

Paulo Tavares
Hi Paulo,

Thank you for your reply.  We will follow your suggestion and check with support.

Best Regards,
Luís Dias

Hi,

I've found this article published by OutSystems support which instructs how to prevent session fixation:

https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/How_OutSystems_Platform_helps_you_develop_secure_applications/02_Protecting_OutSystems_apps_from_authentication_vulnerabilties

Look for the use case "Force session ID regeneration on login" - by following the instructions you will be able to create a new session ID everytime the user logs in thus invalidating any session fixation attempts.

Regards,

Rui

Hi Rui,

Though I applaud your attempt to answer a question, in this case you're almost six years overdue :). Better check the date on a post first next time :).

Hi

You're right :) I did not pay attention to the post's date :)

Nevertheless, after looking carefully to the info on that page, I found it quite confusing. I'm trying to solve a session fixation issue and my efforts have not been successfull.

Do you have any idea how can I invalidate the ASP.NET_SessionId cookie and force a new one to be generated?

Regards

I'm not sure how old that page is, and whether the information is still current. Unfortunately, I can't help you with that question, as I've got no idea.

Ok - Thanks!

I seem to have found the solution - by using the SetCookie action from the HTTPRequestHandler extension, I am able to set the ASP.NET_SessionId cookie to the empty string which triggers the generation of a new session ID.

Hello Everyone,

I've tested the solution proposed by Rui Lopes and it works, until i've discovered that, in a specific scenario, the Session Fixation Mismatch returns.

Let's say that you have implemented the SetCookie, as Rui Lopes proposed, in the Login of Application A. 

Now let's follow these steps:

1. Navigate to the login screen of Application A but don't perform the login;

2. Open another tab, on the same browser, and login to another Application (Users in my case) and perform the login with a different User from the one that you will use on Application A;

3. After logged in on another Application, try to login on Application A without logout on the another Application that you've logged in on step 2;

There you are, Session Fixation Mismatch again.... 

Hi Pedro,

If I understand your post correctly, your problem is not being able to be logged in with 2 different users on the same OutSystems server, or?

Rui Lopes wrote:

Hi Pedro,

If I understand your post correctly, your problem is not being able to be logged in with 2 different users on the same OutSystems server, or?

Nop.

The problem is that when you try to login in an Application, when you are already logged in in another Application, with another User, the Session Fixation Mismatch problem still occurs.


I followed the steps you described but, when I analyse my HTTP requests/responses, I see different session IDs on both tabs which should mean no session fixation occurs any longer.

Do you have a different result? Please note that I am not an expert on security so I would appreciate if you could detail a bit further your situation because I may be overlooking something.

Thanks!

Pedro Domingues wrote:

Hello Everyone,

I've tested the solution proposed by Rui Lopes and it works, until i've discovered that, in a specific scenario, the Session Fixation Mismatch returns.

Let's say that you have implemented the SetCookie, as Rui Lopes proposed, in the Login of Application A. 

Now let's follow these steps:

1. Navigate to the login screen of Application A but don't perform the login;

2. Open another tab, on the same browser, and login to another Application (Users in my case) and perform the login with a different User from the one that you will use on Application A;

3. After logged in on another Application, try to login on Application A without logout on the another Application that you've logged in on step 2;

There you are, Session Fixation Mismatch again.... 

To be fair, since you're doing everything in the *same* browser window, what's happening here is that it's the browser itself that is sharing the cookie it already has. Note that cookies are not per application, they're per domain so all sites in say *.google.com (mail.google.com, maps.google.com, play.google.com, etc.) will share all google.com cookies within the same browser window.

That's precisely why most, if not all (I didn't check them all!), have a "open new window" option somewhere.

Carlos Ribeiro da Fonseca wrote:

Pedro Domingues wrote:

Hello Everyone,

I've tested the solution proposed by Rui Lopes and it works, until i've discovered that, in a specific scenario, the Session Fixation Mismatch returns.

Let's say that you have implemented the SetCookie, as Rui Lopes proposed, in the Login of Application A. 

Now let's follow these steps:

1. Navigate to the login screen of Application A but don't perform the login;

2. Open another tab, on the same browser, and login to another Application (Users in my case) and perform the login with a different User from the one that you will use on Application A;

3. After logged in on another Application, try to login on Application A without logout on the another Application that you've logged in on step 2;

There you are, Session Fixation Mismatch again.... 

To be fair, since you're doing everything in the *same* browser window, what's happening here is that it's the browser itself that is sharing the cookie it already has. Note that cookies are not per application, they're per domain so all sites in say *.google.com (mail.google.com, maps.google.com, play.google.com, etc.) will share all google.com cookies within the same browser window.

That's precisely why most, if not all (I didn't check them all!), have a "open new window" option somewhere.

Hello Carlos,

I understand perfectly what you're saying but, as you can understand, most of the User will not open links on new window, unfortunately.

I've even tried to force the User Logout before the new Set Cookie but still doesn't work...

Well, the only way around the fact that the browser itself shares session cookies across all the tabs in the same window that I see is not to use cookies.

Luckily the platform makes it easy, simply go to the module's properties, and for the one labelled "use cookies", set it to "No". Oh, and if you're building URLs dynamically you might need to add the session id to them.


Hi everyone,

In a short timeframe you will have protection against session fixation attacks out-of-the-box for the platform. This will work the standard way. Once you login, your cookies will be changed in order to avoid attacks using previously compromised cookies. Some more information, you should not change ASP.Net Session cookie. Our solution will use an alternative cookie.

If you wish to know more about it or be part of a beta test program, drop me a private message.

Hi lef,

Nice to know it will come built-in for OutSystems :). But, meanwhile, you said the ASP.Net Session cookie should not be changed. Can you explain why and what problems may come from that?

Thanks,

Rui

Hi again,

If you try to replace the session cookie you might start receiving two cookies instead of one (due to domain or path mismatchs as you don't know the domain of the cookie you are receiving). Furthermore you will increase the session server load as you are creating a new session without destroying the previous. You will also not be able to replace the session and login in the same server request. Finally, none of that is a supported configuration from OutSystems, and it will not work with the upcoming mechanism.

Cheers


 

Rui Lopes wrote:

Hi lef,

Nice to know it will come built-in for OutSystems :). But, meanwhile, you said the ASP.Net Session cookie should not be changed. Can you explain why and what problems may come from that?

Thanks,

Rui



Hi,

Thanks for the feedback!

Regards,

Rui

Hi lef,

And will this also address the problem of users wanting to have different logins in different tabs in the same browser windows? (the problem that Pedro Domingues mentioned)

Hi,

Pedro problems with different tabs are only observed in the solution he implemented. Probably due to the lack of paths in the returned cookies.

Regards

Carlos Ribeiro da Fonseca wrote:

Hi lef,

And will this also address the problem of users wanting to have different logins in different tabs in the same browser windows? (the problem that Pedro Domingues mentioned)