Learn More





Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Session FixationSession Fixation
New Post
3/4/2014 1:24 PM

My client is stating that when they run HP Web inspect against their new DNN portal they are identifying a "Session Fixation" security flaw in DNN.

Has anyone else run into this?

How did you resolve it?

From what I can see from the documentation online to avoid this on login you need to explicitly issue a new ASP.NET_SessionId and on logout you need to explicitly null and\or expire it.


Excerpt from the error description I received

"Session fixation allows an attacker to impersonate a user by abusing an authenticated session ID (SID). This attack can occur
when a web application:
· Fails to supply a new, unique SID to a user following a successful authentication
· Allows a user to provide the SID to be used after authenticating"

New Post
3/4/2014 5:05 PM
if you ever have any suspected security issues please email [email protected], we'll be happy to answer them. As to the issue, first of all it doesn't apply to DNN as we don't use sessions. Secondly if it is an issue it's with and not DNN - If you're not using sessions in your own custom code you might want to apply

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US
New Post
3/4/2014 6:54 PM

The reason this error is reported by a number of different test and site check systems - is that DNN does not null out the sessionid on logout.

I seem to recall some time back that there was a JIRA request for this to be added to the core - but that it was closed with no action.  With the reason being that because of how DNN works there is NO attack risk since dnn does not use the session id for its authentication.

Now while this may be true - it still have implications for some shopping cart type systems that do seem to use the sessionid  -  as such - while it seems like sure it may not - Ive always thought that it should still be happening since it IS considered web best practice to clear sessionid when logging out.

It is however a very simple thing to change if it really bothers you - Basically it involves adding two lines of code to the /DesktopModules/Admin/Authentication/logoff.aspx.cs file - The suggested code is something like the following

private void DoLogoff()

//Remove user from cache

if (User != null)
DataCache.ClearUserCache(PortalSettings.PortalId, Context.User.Identity.Name); }

Session.Clear();             ///  add these two lines
Session.Abandon();      ///  add these two lines

var objPortalSecurity = new PortalSecurity();



catch (Exception exc) //Page failed to load





New Post
3/5/2014 2:01 PM


    Excellent response thanks for the Help. Does it really bother me? No. Does it really bother some security guy sitting around with a new idiot light based scanner that says DNN is unsecure because the lights red? YES. 


    Explanations of why DNN doesnt have to worry about it cause it doesnt use it doesnt change the little light on the security guys terminal to green. There is a new breed of security managers out that just offload responsibility to automagical scanners. The site can be wide open but as long as the lights green the bobble head shakes yes, and until it does the shinny new website can't be deployed. Considering the folklore and horror stories around the DNN core module approval process I would think you'd be more sensitive to the arbitrary red light green light approval processes we all to often face in the wild.

New Post
3/5/2014 2:53 PM

Sorry if I came off as trite, but trust me I know of your pain regarding automated scanners (this month I've received numerous reports, many numbering in the hundreds of pages, one arriving in more than 1200 pages long). These are composed almost entirely of "false-positives", or even worse of warnings about using particular code. One vendor even detects if you are using .net file API's and add's a warning that these may be dangerous - no evidence, no identifying suspect code, just a generic warning that code that does file access may be unsafe - this to my mind is simply padding out reports for their (often overpriced) tools, and all it does is scare people who run them who insist these warnings disappear.

We often "fix" false positives simply to remove them from automated scanner reports, as it's simpler to fix something that is a false-positive rather than have to provide an explanation every time we receive a report about it. However there are cases where we cannot make changes so we simply have to live with the invalid reports and when requested we provide a quick response to confirm that something is a false-positive - this is all I was doing in your case.

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US
HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Session FixationSession Fixation

These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?