I really like this system.
I’d like to build a system to add some of my and my friends‘ important important information into the system. But I’m afraid that our info will be stolen or hacked.
How to protect this system? Or should I just change into another system?
We take security very seriously at Discourse. We welcome any peer review of our 100% open source code to ensure nobody’s Discourse forum is ever compromised or hacked.
You can read more about that at discourse/SECURITY.md at master · discourse/discourse · GitHub
The only way to fully secure any piece of software (online or offline) is to take it to the desert, drop it in a 20ft hole and dump cement over it. So, 100% continuous, permanent security is not possible (just look at Denuvo).
But, if the question is “Is open source software more secure than closed software” than the basic reasoning behind answering this question is that with open source software (that has a large user base with active feedback) that any security exploits get reported quickly, and therefore can get plugged (fixing said security issue) quickly.
There are somethings you can do yourself:
Any member can maliciously still copy/paste the information for the rest of the world to see.
A good thing to know about Discourse based on what I’ve read on this forum/meta is that any image, uploaded document (pdf, word, excel, etc.) can be accessed even when the forum is set to private if somebody from outside the forum knows the exact url for the file.
The main site settings you would want to flip on here
HTTPS, obviously!
secure email (don’t leak content over email)
login required (don’t show content to anons)
account approval required or invite only to taste (don’t allow anyone except people you know / approve) to join
Can you think of anything else here @erlend_sh?
These are great ideas.
Wouldn’t prevent anons from downloading files prevent these kind of things ?
Hi! I totally love Discourse so far for my community’s needs. Thanks so much for building it.
I also do research on the security of open source projects. For this research I rely heavily on the National Vulnerability Database, which is where a lot of major vendors and open source projects disclose their security vulnerabilities (after they’ve been fixed of course).
This in principle makes it easier for people to know if an old version they are using has a vulnerability. It also helps 3rd parties make vulnerability scanning tools.
I am wondering if there is some way to work with the Discourse devs to get them to start working with NVD.
From my perspective that is covered by our security doc in the repo… the first two paragraphs of it specifically… which covers our public bug bounty program URL and where you can click to see a list of security checkins live 24/7.
Don’t nvd work directly with hackerone here? It seems far more beneficial than working directly with Discourse on this.
Thank you for your reply.
Your current security policy is certainly impressive in a lot of ways. However, I still think there are benefits to having your security vulnerabilities reported to NVD that your current policy does not provide.
Now, if I understand correctly, you announce security fixes by having “SECURITY:” in the commit message of the fix.
This is not the same thing as disclosing the vulnerability, which may affect multiple prior versions of the software before the fix.
The way NVD works is that each vulnerability gets assigned a unique identifier, and it tracks which versions of each product are affected by the vulnerability.
So, for example, the Heartbleed bug has an official, standards-compliant identifier, CVE-2014-0160, and a record describing its severity along several dimensions. Other important projects, ranging from Android to MediaWiki to Ruby on Rails, all report their vulnerabilities in this way.
I am not sure about hackerone’s relationship with NVD. Some quick searching implies that they do not work them directly; Intel’s hackerone page requires bug bounty hunters to come up with CVSS vector string for indicating severity using one of the calculators. (CVSS one of the other interrelated NIST standards for vulnerability reporting).
While increasing overhead for bug bounty hunters doesn’t seem ideal, I could see how hackerone would want to give its customer the option of opting out of NVD disclosure. I agree that it makes sense for them to support integration, but I believe that currently they don’t and it’s the responsibility of vendors.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
