Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Security Lessons Learned

securitylessons Over the past couple of weeks, the DotNetNuke project has had to deal with a few different security issues.  As Shaun pointed out in his post, we take these issues very seriously and make every attempt to deal with them in a professional manner.  Even now, as we deal with the latest issue, it is important to note that the security of DotNetNuke is something that impacts everyone in the community.  While the DotNetNuke security team is responsible for isolating and fixing the security issues, there are some things that you as a member of the community can do to help.

Restrict discussion of security issues to official channels

The DotNetNuke team, like most organizations, prioritizes our communications.  Certain forms of communication will result in immediate action on the part of team members, while other channels may go for several hours or even days without being noticed.  If you have a security issue, then [email protected] is the right channel to use, since this email alias is closely monitored by our security team.  If for some reason, you do not get a response here, then direct communication via the phone or IM with a member of DotNetNuke corp will result in prompt attention.  If you have not relieved an acknowledgment within a reasonable amount of time, then a follow-up using a direct communication channel is warranted.  In no case should you make a public posting about the existence of nor the details of a security vulnerability until the team has had a chance to analyze the report and create an appropriate patch and security notice.

Give the team time

Security vulnerabilities are serious problems.  When creating a fix for a vulnerability, we try to be very thorough.  We need to make sure that we fully understand the nature of the vulnerability and that we have a fix that does not further compromise the application.  It is not uncommon to find out that what at first seemed like an isolated issue may in fact have a wider impact than first assumed.  Once a fix is created and the issue is reported in a security notice then hackers will begin analyzing the system to see if they can get around whatever fix is put in place.  If we did not spend time to make sure that we fixed the problem completely, we could end up just highlighting a problem rather than actually fixing it.  Generally speaking, once we have acknowledged that a problem exists and have enough details to reproduce the bug, then we will work internally to create a fix.  During this time we will not likely have any further discussion with the person originally reporting the issue.  Once we have the fix completed we may give a brief update to the person reporting the issue and may even enlist their assistance in testing the fix.  Do not think that because we have not talked with you in a few days that nothing is happening.  Depending on the nature of the issue it may take anywhere from a few hours to several days to actually find an acceptable resolution.

Follow good security practices

Users often get very nervous whenever word of a new vulnerability comes out.  This is understandable.  However, by following good security practices, you minimize your risk which means you are less apt to push us to deliver a fix before we fully understand the problem and the correct solution.  Some simple steps you can take to minimize your risks -

Make frequent backups

The more critical your data is, the more frequently you should make backups.  If you have a backup, then dealing with a site-defacement becomes a minor annoyance and not the end of the world.

Minimize the number of installed extensions

Every new module and skin introduces the potential for new attack vectors.  If you are not using a module then uninstall it.  If you are not using a provider then delete its assemblies from the /bin folder. 

Use trusted extensions

Modules, providers, skin objects and even skins pose a potential security threat.  You should be selective in what you install on a production system.  If you want to test out a new module from a vendor who you don't know, then do so in a sandboxed system.  Monitor the behavior of the module to ensure that it is not doing anything malicious.  If you have the skills, examine the code or look at the network traffic to ensure that there is nothing hidden going on in the background.

Don't share logins and passwords across sites

People have trouble remembering the username and password that they use for various applications and websites.  Invest in a good password manager that will allow you to create unique accounts for every site and application.  Once you have a password manager, be diligent in using it.  Your site/server is much more secure if the username and password is unique for that site.  Using a password manager means that you are much more likely to choose a secure password rather than worrying about creating something that is easy to remember.

Give users the least privileges needed to do their job

Even though you may trust a user with a host account, you should not give them host privileges unless they absolutely need those privileges to perform some task.  In past versions of DotNetNuke we made it difficult to apply this principle.  Often people were given full administrative privileges because they needed access to a single feature which was only available to admins.  There was no way to give them access to that one feature.  We are significantly improving this in DotNetNuke 5.0 by allowing access to admin modules to be delegated to users or groups.  We are also adding in the ability to deny permissions to a specific user or group.  These two changes will help ensure that you have the level of control needed to adequately lock down your site without impairing your ability to delegate administrative tasks as needed for your particular business processes.

In the end, good security relies on following well established practices.  As we resolve the current security issues and move past the events of the past few days, I hope people will keep these tips in mind.  I think they will go a long ways towards reducing problems in the future and ensuring that we can continue to put out a secure web application framework that will continue to be trusted by users all over the globe.


Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (22)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (270)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?