PowerDNN

1.  Introduction
The DotNetNuke Web Application Framework is a powerful system for designing online websites and online web applications.  When designing a DotNetNuke hosting infrastructure, security is one of the most important aspects to  consider when planning for high reliability and uptime.  Although the DotNetNuke application itself has been thoroughly tested and has undergone extensive third-party security audits, an insecure or improperly configured hosting environment will nullify the security benefits provided by the DotNetNuke Web Application Framework.

2.  Purpose
The purpose of this document is to provide a best-practices document for DotNetNuke implementers to follow when  implementing a DotNetNuke hosting environment.

3.  Assumptions
This document assumes that you are implementing a standalone DotNetNuke hosting infrastructure and that it is not  running in a web farm, web garden, or SQL Server Cluster.  When implementing DotNetNuke in one these advanced configurations, additional security precautions must be taken into consideration that are not discussed in this document.

4.  Database Configuration
When configuring the database for your DotNetNuke application, it is very important that the DotNetNuke application have its own database and its own database user.  The user should be configured with a unique, random password at  least 8 characters long and should not be an SA user (System Administrator).  Two common mistakes that people make are  1) using the SA account for the DotNetNuke Database and 2) using the same database user for multiple databases.  The reason that using the SA user is bad is because the SA user has complete control over the SQL Server including doing things like creating and deleting databases and managing internal security.  If this account gets compromised, then the attacker will have complete control over your SQL Server.  The reason that using the same user for multiple databases is bad is because it will then be possible to execute SQL queries against multiple databases which could potentially allow a DotNetNuke website to access another DotNetNuke website's database.

To overcome this problem, generally it is a good idea to use a standard naming convention for all website connection information.  For example, if you have a site named "MySite.com" any one of the following naming  examples would be good:

Database Name:  MySite
Database User:  MySite
Database Password:  fgsdf&#$AD1

Database Name:  MySitedb
Database User:  MySiteuser
Database Password:  fgsdf&#$AD1

 5.  Web server Configuration
When configuring the web server for DotNetNuke, there are operating system, IIS, and ASP.NET level security precautions to consider.  The following will take a top-down approach when describing the configuration.

5.1  Application Pool
In IIS, an Application Pool is a collection of web applications that run together in the same execution context.  Each DotNetNuke application should be set up and configured in its own, unique application pool which is running under its own, unique windows login account, neither of which should be "Network Service" or "Local System".  If two websites are executing in the same application pool, it is possible for one website to malfunction and impact the reliability of all other applications in the application pool.  If two websites are running under the same windows account, it is also possible for one website to "reach" into another website and alter or control the other website's files.  The reason that the "Network Service" account should be avoided is because this is a common user that exists on many computers.  The "Local System" user has complete control over the entire server including internal windows files and the registry.  Using the "Local System" user will greatly increase the amount of damage that can be done by a rogue or malfunctioning component.

5.2  Web Server File Security
Once you have the application pool configured, you will then need to configure windows permissions on the application files themselves.  You will need to make sure that the user that runs the application pool has the right permissions to the file system.  If the website is a read-only brochure site, then for added security, you may want to consider making the entire web folder be READ ONLY, however, in most environments, FULL CONTROL is perfectly acceptable and is recommended.

5.3  ASP.NET Trust
Although there is much discussion about what trust level is the best (Medium Trust vs Full Trust), it really boils down to the trust that you have in the code that your application is running; and, if you have followed the previous steps, it really should not matter much.

If you are not familiar with ASP.NET Trust levels, ASP.NET has the ability for you to determine how much trust you personally have in the code on your website.  The lower a website's trust level, the less .NET function calls they will be able to execute, for example, a Low Trust application will not be able to make web service calls.  This is particularly useful when executing third-party code.

If your organization has strong code review processes in place and you are only using DotNetNuke Core Modules and modules developed by reputable vendors, then it is perfectly acceptable to execute in Full Trust.  However, if your application uses unverifiable code or relies on components of questionable origin, then you should use Medium Trust to protect yourself against malfunctioning or poorly designed code.

When choosing a trust level, it is best to make a judgment call and ask yourself "Do I trust the people who have written the code for my application?".  If your answer is "YES", the use Full Trust, if your answer is "MOSTLY", then use Medium Trust, and if your answer is "NO" then you should consider finding an alternate component from an alternate vendor to service your needs.

6.  Conclusion
Although many of the policies here are generally considered non-standard when setting up a development DotNetNuke application, it is important to follow these security configurations through the entire application lifecycle including development, staging, and production.

7.  General Q & A
Q:  Why don't you suggest encrypting the SQL Server connection strings?
A:  Although encrypting the SQL Server connection strings will prevent a system administrator from easily knowing the connection strings, it will not prevent a skilled attacker from discovering the SQL Server logins and  passwords.  If an attacker has access to the website's root directory (which would be needed to steal the web.config), simply injecting the right code will display the contents of the encrypted connection strings.

Q:  Does PowerDNN implement all of these security precautions?
A:  Yes.  Each site has its own database, own user, own password, own application pool, and own identity.  By default we run all websites in full trust, but we also allow our customers to change that configuration if they want as well.