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:
I've found this article published by OutSystems support which instructs how to prevent session fixation:
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.
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 :).
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?
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.
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....
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:
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.
Pedro Domingues wrote:
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:
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...
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.
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?
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.
Thanks for the feedback!
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)
Pedro problems with different tabs are only observed in the solution he implemented. Probably due to the lack of paths in the returned cookies.