Please note, all suspected security issues should be sent to community.security@dnnsoftware.com.
This
is a false-postive. That is behaviour by design. This is a standard asp.net 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 asp.net practice and DNN does not do anything
different here, except in one respect where we improved upon asp.net’s behavior by introducing an additional
value that would allow different timeouts to be specified for temporary and
persistent forms authentication cookies (http://www.dnnsoftware.com/wiki/page/...).
Note: we support the ability to disable persistent forms auth cookies (via
“remember me”) as an installation setting - see http://www.dnnsoftware.com/wiki/page/...
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, asp.net 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
asp.net 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”/>