Background

The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software. Every year they publish a list of "top-10" security vulnerabilities in web applications. Due to their position as an independent authority many organizations use this as a base on which to validate how secure their applications are.

OWASP Top 10

The current (and previous) top-10 list can be found here. As 2011's list has not yet been created the latest version is the 2010 one (document available at here).

The following sections contain a list of the items from the 2010 list, with a brief description followed by how DotNetNuke protects against these issues.

A1 – Injection

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

DotNetNuke core and core module projects all utilize stored procedures exclusively and security checks are performed to ensure that these stored procedures do not concatenate SQL meaning that SQL injection cannot be performed (there is some more detail on this at here)
Please note, the core reports module does allow for arbitrary SQL to be ran, as does the host->sql module, however both are locked down to only allow Host (superuser) access to create the queries. Care should be taken if choosing 3rd party modules that allow dynamic/arbitrary sql to ensure they have applied similar protection or that they utilize the core InputFilter library with the NoSQL enumeration to sanitize values passed to a function that concatenates SQL.
DotNetNuke does not contain code that injects into the OS or LDAP processes (note: the active directory provider accesses Active directory, which uses LDAP2/3, however the code uses Microsofts libraries which correctly sanitize any inputs)

 

A2 – Cross-Site Scripting (XSS)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

DotNetNuke takes care to sanitize any user submitted data, including text entered, cookie values, http servervariables, querystring and form parameters (i.e. anything passed as part of a HTTP request). Typically DotNetNuke will encode any data that does not require HTML, and in cases where HTML is required will run the input via the core InputFilter function with NoScript enabled to strip any potential html/script injection.
In addition to this, as part of a defence-in-depth process, we have core code to ensure that in the case of a successful XSS attack that the cookies (including the users authentication cookie) cannot be stolen. Please see here for more details on the usage of the HttpOnly attribute.
 

A3 – Broken authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.

DotNetNuke leverages Microsoft's membership providers as the basis of user authentication. These have been extensively tested and are well regarded. These support both encryption and hashing for user password storage. Encryption uses a strong cryptographic library and in addition implements a unique SALT value for each user to ensure that passwords cannot be cracked by using known strings (i.e. a dictionary or rainbow table account).
In addition DotNetNuke has code that only allows for a limited set of failed attempts before the user is locked out, which adds a further layer of protection.

 

A4 – Insecure Direct Object References

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

DotNetNuke supports the concept of folder types (with the 6.0 release these are known as folder providers). As such files the user uploads can be in a folder that implements the required level of security e.g. a folder can be set to be "secure filesystem" and files will then have a .resources added to their file (e.g somefile.img.resources). This means a direct reference to that file will fail as DotNetNuke maps the .resources extension to a failed request handler - this ensures the file will not be served up and also will not even indicate if such a file exists. Similarly the "secure database" option places files in the database meaning they cannot be accessed via a direct reference. Such requests go through DotNetNuke's "linkclick" handler which first validates the user, then checks if they are authorized to access the file before serving the file up if they are.


 

A5 – Cross-Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

DotNetNuke uses the viewstateuserkey property that is a part of asp.net to stop CSRF issues. On each DotNetNuke request we add a unique identifier to the view-state variable for individual users so that they cannot use the variable to generate an attack. Further details on viewstateuserkey can be read here
Note: in addition we ensure that we encrypt the viewstate and also add a unique MAC value to it to allow us to determine if an attempt was made to alter it.

A6 – Security Misconfiguration

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.

DotNetNuke uses a sensible set of security defaults that are strong. However it is possible to update these if an individual installation requires stronger protection e.g. the default minimum password length is 7, but a site may want to make that larger or perhaps require a more complex password (e.g. one that contains a number of non-alphanumeric characters).
The "hardening DotNetNuke installations" document details a number of ways a site may enhance security.
Please note, DotNetNuke has a dedicated security team who regularly review the core for security issues, and who do module audits on all core modules to ensure they have no security issues, to ensure a solid baseline of security. In addition this team looks to add additional protection ("defence-in-depth") and enhance existing mechanisms.

 

A7 – Insecure Cryptographic Storage

Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.

As previously mentioned DotNetNuke uses the Microsoft membership provider as the basis of our user security. By default this uses Triple-DES (3DES) which is a popular strong encryption method - cracking it's keys are not currently practical, with general opinion being that it will be 2030 before technology has advanced enough to crack it in a usable time -
In addition as DotNetNuke uses a unique SALT value for each user and also limits the number of attempts before an account is locked, as well as storing the key separate from the database, DotNetNuke's storage is secure.
For sites that want to be particularly secure they may opt to use hashing instead of encryption - as hashing is a 1-way operation the password cannot be cracked. This can be done via a simple web.config change.

 

A8 - Failure to restrict URL Access

Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.

All requests in DotNetNuke go through a single page, default.aspx. This ensures that all requests are checked that the current user has authorization to access that page. DotNetNuke uses a rich set of controls, allowing permissions to be set at both the user and role level, as well as allowing the particular action permission to be defined i.e. if a user can view or edit a page/module.
In addition to ensure that if a user loads a page but then tries to access a function they should not (e.g. a function that is invisible or disabled), DotNetNuke uses asp.net's EnableEventValidation feature. This forces ASP.NET to validate that a control event originated from the user interface that was rendered by that control, which foils attempts to do POSTBACK based attacks or to alter control contents via javascript hacking/HTTP Proxies. A control registers its events during rendering and then validates the events during postback or callback handling. For example, if a list control includes options numbered 1, 2, or 3 when the page is rendered, and if a postback request is received specifying option number 4, ASP.NET raises an exception. All event-driven controls in ASP.NET use this feature by default.

 

A9 - Insufficient Transport Layer Protection

Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.

This is more of a webserver issue than a webapplication issue i.e. what version of TLS/SSL the webserver supports etc. However DotNetNuke has integrated support for enabling SSL on pages and also setting so a page can only load under a HTTP (SSL) request.

 

A10 – Unvalidated Redirects and Forwards

Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

DotNetNuke does contain a number of pieces of code where an original request URL is passed along e.g. an attempt to access a page the user does not have access to will result in a redirection to the login control if they are not logged in. On successful login the user is then redirected back to the original request. To ensure that this redirection URL is not altered, DotNetNuke checks and will ignore any request that contains a protocol (e.g. the http part of http://hackersite.com). In addition it will check if the request's domain is a valid portal alias and if not will ignore the value.