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.

Module uninstalls and security best practices

During the DotNetNuke Review process, one item that we look for is whether a module can be completely uninstalled using either automated or manual procedures (assuming the manual steps are documented).  Uninstallation will be viewed by some users as a measure of quality.  In addition, failing to properly remove a module poses a potential security risk for many sites.

One key identifier for malware is that it makes it difficult, if not impossible, to uninstall.  Any software which resists attempts at removal presents a problem for users and administrators and is a generally frowned upon practice.  One of the primary goals of the Review Program is to help improve the overall quality of modules available to users (this includes both actual and perceived quality).  We feel that not hampering users ability to remove the module is a key part of meeting this goal.

More important than the quality issue however, is the issue of security.  Imagine if a user were to install your module and decides to remove it.  You subsequently discover a vulnerability in your module and distribute information to your user community on how to patch your module to correct the problem.  What should an administrator do if they have previously uninstalled your module?  What if this administrator is not the one who did the initial installation/uninstallation?  The odds are pretty good, that if an administrator believes that a module has been uninstalled that they will ignore your security bulletin (how many administrators that have your module installed ignore your security bulletins - my bet is that it is a much larger number than you think).  So under certain circumstances, it is possible that not properly uninstalling a module could leave you open to hackers.

So where does that leave us.  I believe that this requires action by both the DotNetNuke team and Module developers.  Currently, DotNetNuke attempts to execute the unistall script and delete the module folders when a module is deleted from the Module Definitions screen.  However, in some cases the uninstall script may fail or the directories are not properly removed.  It is also possible that a module might create additional directories in other parts of the system that is not detected by DotNetNuke.  We need to make the uninstallation more robust to provide information about what steps were taken during uninstallation, and which steps were not completed due to errors in the process.  We also need to provide some APIs that allow the portal to keep track of what changes a module is making to directories.

The solution must also include action by the module developer community.  Module developers should include instructions for completely removing a module.  This should include all files, folders and database objects.  While DotNetNuke will continue to improve in this area, it is unlikely that the framework will ever be more knowledgeable of your module than you, the developer.  You have intimate knowledge of the directories that are created and of the stored procedures and tables that are created or altered.  By providing manual uninstallation procedures you tell your users that you are a responsible developer and increase the perception of quality in your company and your products.


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 (21)
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 (269)
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?