Skip to main content
Home  ›  Blog

Security First Strategy for 2sxc 9.30+

Security is like money - it's no problem when you have enough. And it becomes a real problem, when you don't have enough. 2sxc is going to raise the bar now, with a threefold security strategy. Here's what you need to know.

3 Part Security Management Strategy

What we're currently looking at is not the classic "let's write good code" - that's a general requirement. We're talking about the entire level around it - here are our core rules, applicable to 2sxc 9.30 and up:

#1 Minimize the Surface

Enable only the features that are in use, and the system must ensure, that other features are disabled. This is in line with other products like windows server because it shrinks the security-affected surface area.
Note that we'll go slow on this and leave all current features as-is, because it would otherwise break existing installation. All future features that could somehow be security-relevant will need active enabling.

#2. Single point of contact for security issues

please mail us at security@2sxc.org
It's important that we don't discuss possible security issues on public platforms like github, as this would put all existing users at risk.

#3. Actively Inform Affected Users of Security Issues

If a security issue is relevant, we will actively inform users of these issues - both when they intend to enable a feature and if they already have the feature enabled. This is tightly coupled to the Minimize-Surface strategy.

Security Related Features

So far 2sxc was primarily used for content which was edited by logged in users. But the newest release (9.30) will provide many features making 2sxc viable for public data-input, like for contact forms or databases, where public users add something, which will be released / processed by someone authorized.

This is a big step: most security breaches nowadays revolve around such functionality. For example, if the file-uploader isn't perfect, people could upload bad files resulting in XSS (Cross-Site-Scripting) or even worse: remote-control of bad people.

So such a feature will only work if the public-forms and public-upload is enabled.

Informing Affected Users

This is an extremely important step: users who are using these features must be the first to hear of any issues. This is why such features will have a security-information (green/orange/red) which is tied to their version of DNN, 2sxc and more.

In addition, we'll keep track of who is using what features, that we can actively send them an e-mail if they are effected. Note that for this we also needed an ability to identify installations using a fingerprint - read about it in this blog. Because as Stalin once said…

…Confidence is good, Control is better

Love from Switzerland,
Daniel


Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 800 DNN projects since 1999. He is also chief architect of 2sxc (see github), an open source module for creating attractive content and DNN Apps.

Read more posts by Daniel Mettler