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 ...Logout does not kill all sessionsLogout does not kill all sessions
New Post
1/30/2015 1:56 PM
I have no idea how to correct this. It seems like a security issue and I have not been able to find any information on how to fix this issue.


    Windows 7, Chrome Browser, Edit this Cookie extension
    VM running KUbuntu desktop, Chrome Browser, Edit this Cookie extension
    DNN HTTPS Site with use logins

    Using the Windows 7 system go to the DNN site and login.
    Using the Edit Cookie extension to export all cookies from DNN page to the clipboard.
    Paste cookies into text editor, re all cookies except .DOTNETNUKE cookie.
    Copy to clipboard.
    In KUbuntu VM select Edit this Cookie extension and select import cookie.
    Paste cookie into dialog and select the check.
    Copy URL from Windows 7 browser into KUbuntu browser and use return.
    KUbuntu system goes to the web page without authenticating.
    Both browsers can move around web site.
    In the Windows 7 browser select logout, browser page goes to the login page.
    KUbuntu browser can navigate site because it is still logged in.

Information found:
On the DNN site ( shows a way to timeout session by inserting:
    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

Adding the two lines do not fix this continuous logon. This is an issue for our PCI penetration test. What has to be done to invalid the second session when the primary session logs off?
New Post
1/31/2015 11:01 AM
Please note, all suspected security issues should be sent to [email protected]

This is a false-postive. That is behaviour by design. This is a standard forms authentication cookie which contains an expiration date value i.e. there is no server-side value to expire. Sites can control the expiration of this cookie via the forms node timeout, and there is code to ensure that the cookie cannot be tampered with or decrypted (as well as code to ensure that it cannot be captured via javascript). The reason the cookie does not create a new session on login is that the forms authentication cookie contains its own expiration date. This is standard practice and DNN does not do anything different here, except in one respect where we improved upon’s behavior by introducing an additional value that would allow different timeouts to be specified for temporary and persistent forms authentication cookies ( Note: we support the ability to disable persistent forms auth cookies (via “remember me”) as an installation setting  - see

Finally, session replay attacks require cookies to be captured. The most common way to do so is via malicious javascript. DNN implements protection for this via the HttpOnly attribute which we apply to all cookies -the HttpOnly attribute directs browsers to use cookies via the HTTP protocol only. An HttpOnly cookie is not accessible via non-HTTP methods, such as calls via JavaScript (e.g., referencing "document.cookie"), and therefore cannot be stolen easily via cross-site scripting attacks.

The other way that a cookie can be stolen is if it is intercepted during transmission by a node on the network (e.g. a load balancer, firewall, router etc.). Whilst this is less common, has standard protection for this which is to ensure that the cookie is only transmitted over a secure channel (i.e. HTTPS). To do so, a secure attribute must be set on the cookie. As we do not know in advance if a site has SSL enabled, we cannot set that value for them. However, it’s extremely easy for a site to set that value for themselves. To do so, simply edit web.config and set requireSSL to true on the httpCookies node i.e. the default in DNN looks like this:


<httpCookies httpOnlyCookies="true" requireSSL="false" domain="" />


This should be updated as so:

<httpCookies httpOnlyCookies="true" requireSSL="true" domain="" />


Note: some sites don’t both setting the attribute on all cookies, as mostly they contain harmless information. Typically only the forms authentication cookie is the target of interception so allows the requireSSL attribute to be set just for that cookie i.e the default looks like this:


<forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" />


And the secure version would look like this:

<forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies"  requireSSL=”true”/>

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US
HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...Logout does not kill all sessionsLogout does not kill all sessions

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?