Applying NWebSec.SessionSecurity to a legacy ASP.NET Web Application


One aspect of my 'Day Job' involves remediating security issues that are found in a legacy web application that we maintain. A vulnerability scanner was used against the web application and we discovered that we should improve our session security to something beyond what is offered out of the box in ASP.NET.

I stumbled across NWebSec.SessionSecurity, which seemed to be the answer to my problems! Unfortunately for me the straight-forward implementation instructions provided on GitHub did not work for me, I had to dig a little deeper.

===

One aspect of my 'Day Job' involves remediating security issues that are found in a legacy web application that we maintain. A vulnerability scanner was used against the web application and we discovered that we should improve our session security to something beyond what is offered out of the box in ASP.NET.

I stumbled across NWebSec.SessionSecurity, which seemed to be the answer to my problems! Unfortunately for me the straight-forward implementation instructions provided on GitHub did not work for me, I had to dig a little deeper.

References

 

Problem that we're trying to solve

By Default ASP.NET leaves a lot to be desired in terms of resilience to Session Fixation attacks. NWebSec helps protect against fixation attacks by changing the ASP.NET Session ID after a user authenticates, which makes it virtually impossible for an attacker to fixate a session.

While there are a number of components to NWebSec that address various security issues, we're focusing here on Session Security.

Here's what I see in our legacy web application:

Pre-Login

ASP_NET_Session_Pre_login.png

 

Post-Login

ASP_NET_Session_Post_login.png

 

As you can see, the ASP.NET Session Cookie (W2K12 here) does not get changed after a user logs in. This effectively lets the user specify which session they want to connect to, which helps facilitate Session Fixation attacks.

 

 

Installation path suggested by the documentation

The installation instructions are pretty straight-forward on the NWebSec GitHub:

  • Install the NWebSec.SessionSecurity NuGet package
  • Edit the Web.config file that pertains to your ASP.NET Web Application with a few NWebSec specific entries
  • Note that everything's disabled by default, so you need to enable the session fixation protection in config

 

When I tried these instructions I noticed that there was no change in behavior. When monitoring the login process using browser debugger tools, I still found that the session cookie was unchanged after login.

In addition, the cryptic line in the documentation about "everything's disabled by default" was confusing as I did not see anything that was, in fact, disabled. After banging my head on this for a little while I realized that this was probably just 'stale' documentation. The NuGet package modified my Web.Config file with all the appropriate entries (I just had to move them around a little).

For reference, here are the Web.config entries mentioned on the GitHub site (Watch out for spaces: I needed to add some to the tags to get my crummy CMS to display it here):

< configuration>
  < configSections>
    < sectionGroup name="nwebsec">
      < section name="sessionSecurity" type="NWebsec.SessionSecurity.Configuration.SessionSecurityConfigurationSection, NWebsec.SessionSecurity, Version=1.1.0.0, Culture=neutral, PublicKeyToken=3613da5f958908a1" requirePermission="false" allowDefinition="MachineToApplication" />
    < /sectionGroup>
  < /configSections>

< system.web>
    < sessionState sessionIDManagerType="NWebsec.SessionSecurity.SessionState.AuthenticatedSessionIDManager, NWebsec.SessionSecurity, Version=1.1.0.0, Culture=neutral, PublicKeyToken=3613da5f958908a1" />
< /system.web>
  < system.webServer>
    < security>
      < requestFiltering>
        < hiddenSegments>
          < add segment="NWebsecConfig" />
        < /hiddenSegments>
      < /requestFiltering>
    < /security>
  < /system.webServer>
  < nwebsec>
< sessionSecurity xmlns="http://nwebsec.com/SessionSecurityConfig.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="NWebsecConfig/SessionSecurityConfig.xsd">
    < /sessionSecurity>
  < /nwebsec>
< /configuration>

 

 

So, what now?

The simple install instructions failed me, so I googled NWebSec.SessionSecurity. I checked StackOverflow. It's interesting to see just how little information there is about NWebSec out there on the interwebs, so I was not able to find any information that could help me figure out what to try next.

Feeling a little exacerbated, I poked around in the legacy web-app's code base trying to see if the previous maintainers were going 'off the rails'. In investigating the code I found that the original devs were using code like this in a few places:

System.Web.SessionState.SessionIDManager manager = new SessionIDManager();

 

In looking at the NWebSec Web.config file, I noticed a reference to AuthenticatedSessionIDManager (A class provided by NWebSec). Hmm...

 

The Resolution

I changed each instance of SessionIDManager to AuthenticatedSessionIDManager and rebuilt the application. Lo and behold: The ASP.NET Session key was now updating after users authenticated!

The simplicity and straight-forwardness of the 'suggested' installation path lead me to believe that no code changes were required to get implement NWebSec. It seemed like it would 'magically work'. Once I was able to disillusion myself, I made the necessary code-changes to the legacy web app and was able to move on to other things.