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 for 2013
OWASP periodically update their top 10 list to help site owners, developers and security professionals audit their sites for compliance. The wiki already has a page for
Analysis of DotNetNuke compliance against OWASP Top 10 (2010) -this page will cover the same analysis for 2013.
The current (and previous) top-10 list can be found here.
The following sections contain a list of the items from the 2013 list, with a brief description followed by how DNN 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 – 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.
A3 – 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.
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 – 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.
A6 – Sensitive Data Exposure
Whilst sensitive data such as credit cards are more of an extension level issue (e.g. if a user installs a commerce extension) as we do not store these within the default codebase, there are a number of places where data that is stored within DNN could be regarded as sensitive. First of all would be a users password. DNN has stored user passwords via SHA-1 hashes (with a SALT) since 7.0.0 - this ensures that even if a site is compromised the users password cannot be retrieved. Elsewhere within DNN there is the ability to store a password for access to the DNN Extension catalog - whilst this is an optional function, the data is safely encrypted.
DNN also has full support for indicating that pages support SSL, either optionally or enforcing a requirement for an SSL connection to ensure data only travels over TLS. In addition, as an asp.net website, a site administrator can enabled requireSSL in the web.config to ensure that any data transferred in cookies is protected.
Finally, the majority of cryptographic code within DNN only uses the libraries from the FIPS 140 validated cryptographic modules.. There are a few exceptions to this for functions that only need to obfuscate data and not encrypt it.
A7 – Missing Function Level Access control
DNN has a rich permission model which allows sites to closely control who can access pages or/and modules. These can be applied at both security role or user level. The Evoq products extend this with additional granular permissions to support other permissions such as add, add content, manage etc. In addition, module developers can add their own custom permissions which can then be revalidated at the method (function) level to ensure that a user has the rights to perform an action.
DNN has protection against attempts to access permissions/events outside the users remit and will detect and reject these events (in asp.net terms this is known as Event Validation), and any sensitive methods have additional validation checks to ensure that code cannot be executed outside it's "trust boundary" e.g. attempts to use the SQL module by anyone other than a superuser will fail.
Finally, DNN allows users to develop services via the service framework. This can allow webpages, mobile and client applications and other endpoints to access and run services within a DNN website. Whilst this leverages Microsofts WebAPI platform, DNN extends that and sets a higher default level of security where a user must be a superuser to call a service. In this fashion we can ensure we are "safe by default" as a developer must explicitly allow a user/group access to a service framework method .
A8 – 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.
A9 – Using components with known vulnerabilities
DNN tracks all usage of 3rd party components for vulnerabilities and updates accordingly - we have a dedicated security team which subscribes to vulnerability tracking lists and security websites to ensure that any issues are detected and resolved in a timely fashion. The full list of 3rd party components in use can always be found in the "Licenses" folder.
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.