Hello,
Please feel free to forward any comments to the security team at security@dotnetnuke.com, but let me quickly answer a few of these
DNN requires that the database account run in the database owner role. This means that a successful SQL Injection attacker has full control of the database.
This is incorrect, you can run with non-dbo users fine (e.g. http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/1044/Most-Under-Used-Security-Feature-in-DNN.aspx). In fact the only reason we even require some of those permissions if because of the Microsoft memberrole provider, DotNetNuke can operate in a lower security context than the Microsoft scripts require.
No pages perform input validation. This is the #1 vector for SQL Injection attack.
This is completely incorrect. I can only assume that this comes from the fact that we disable validateRequest?. We do this as it's trivially easy to work around it as it has a fairly limited set of checks - simple addition of non-printing characters/encoded contents/unexpected sequences make it virtually useless.We have our own core input filtering system, that provides html encoding, filtering for javascript/cross-site scripting, and filtering for sql injection (for 3rd party modules who choose to use it)
In addition, in DotNetNuke we only use stored procedures, and do not use concatenated/dynamic sql generation, meaning that sql injection is virtually impossible.
Querystring parameters are not checked. This is the #2 vector for SQL Injection
see above
The database and admin credentials are in clear text
if you don't want database credentials in cleartext, use windows authentication, not sql authentication. There are also a number of options to encrypt the web.config.
Key functionality in DNN requires that a number of .NET security features be turned off
I assume this means validateRequest (answered above)
Strict type checking is turned off for the entire application
this is a legacy setting, that is also the vb.net default. As .net doesn't suffer from buffer overflows it's not a security issue.
DNN needs to write to its own ready-only config files from pages with no security
I don't know what this means. To update the configuration of dotnetnuke, you typically need to be a host (superuser). All user passwords are encrypted (with a SALT value), and DotNetNuke can be set up to require SSL for login.
DNN requires elevated file permissions to run because it does some low level file editing for no apparent reason
It does not need elevated permissions to run. It requires read, write and modify for a number of folders. Most ISP's simply grant these permissions at the root folder, but you can run as read/write in all folders and only add modify permissions to a number of folders e.g. bin (where uploaded dll's go), app_code (for uploaded wsp modules), portals (to allow users to upload files etc.) and desktopmodules (where modules install).
Some modules have hard coded configuration, which means that if we fixed the above issues, the modules would have to be re-written
I was able to delete all the DNN tables with a simple querystring attack.
In that case it appears that your site is running a 3rd party module that accepts sql strings via the querystring. This is obviously not wise. We extensively audit all dotnetnuke core modules, but obviously have no control if you use a 3rd party module that (a) uses dynamic sql and (b) does not validate input. The fact that a 3rd party module does this does not reflect from our long standing good record on security IMO.
Code quality analysis
Please send me a copy of your code quality analysis report, I'd be very interested in what setttings you used. It's trivial to get one of these reports to report high numbers of issues (e.g. get fxcop to inspect it;s own dll's and it'll report huge amounts of non-compliance)
Personally, I would take the fact that hundreds of thousands of dotnetnuke sites have been running for years without major issues as better evidence than a code analysis tool that works off Microsofts subjective ratings.
Finally, DotNetNuke does not suffer from any known memory leak issues.
IMO whoever gave you these details did not do a very thorough job of analysing DotNetNuke, as it would have been trivial to discover that we don't use dynamic sql and had our own custom filtering support.