Discource-C
/
discourse
mirror of https://github.com/discourse/discourse.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

cross-links and copyedits

This commit is contained in:
Jeff Atwood 2013-07-30 13:57:15 -07:00
parent 882c1524f7
commit c3f3c1a23f
1 changed files with 20 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
docs/SECURITY.md
View File

@ -1,38 +1,40 @@
##Discourse Security Guide
The following guide covers security regarding your Discourse installation
If you are reporting a security issue with Discourse, please email `team@discourse.org` -- we take security reports very seriously and will investigate ASAP.
We take security very seriously at Discourse. We welcome any peer review of our 100% open source code to make sure that nobody's Discourse forum is ever compromised or hacked.
Here are a few specific ways Discourse is as secure as we could make it:
###Password Storage
Discourse uses the PBKDF2 algorithm to encrypt salted passwords. This algorithm is blessed by NIST. There is an in-depth discussion about its merits in http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage.
Discourse uses the PBKDF2 algorithm to encrypt salted passwords. This algorithm is blessed by NIST. Security experts on the web [tend to agree that PBKDF2 is a secure choice](http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage).
**options you can customise in your production.rb file**
pbkdf2_algorithm: the hashing algorithm used (default "sha256")
pbkdf2_iterations: the number of iterations to run (default is: 64000)
- `pbkdf2_algorithm`: the hashing algorithm used (default "sha256")
- `pbkdf2_iterations`: the number of iterations to run (default 64000)
### XSS
The main vector for XSS attacks is via the "composer", as we allow users to generate rather rich markdown we need to protect against poison markdown.
The main vector for XSS attacks is via the post composer, as we allow users to enter Markdown, HTML (a safe subset thereof), and BBCode to format posts.
For the composer there are 2 main scenarios we protect against:
There are 2 main scenarios we protect against:
1. Markdown preview invokes an XSS. This is severe cause an admin may edit a user's post and a malicious user may then run JavaScript in the context of an admin.
1. *Markdown preview invokes an XSS.* This is possibly severe in one specific case: when a forum staff member edits a user's post, seeing the raw markup, where a malicious user may have inserted code to run JavaScript. This code would only show up in the preview, but it would run in the context of a forum staff member, which is *very* bad.
2. Markdown displayed on the page invokes an XSS.
2. *Markdown displayed on the page invokes an XSS.* To protect against client side preview XSS, Discourse uses [Google Caja](https://code.google.com/p/google-caja/) in the preview window.
To protect against client side "preview" XSS, Discourse uses Google Caja https://code.google.com/p/google-caja/ in the preview window.
On the server side we run a whitelist based sanitizer, implemented using the [Sanitize gem](https://github.com/rgrove/sanitize). See the [relevant Discourse code](https://github.com/discourse/discourse/blob/master/lib/pretty_text.rb).
On the server side we run a whitelist based sanitizer, implemented using the Sanitize gem https://github.com/rgrove/sanitize see: https://github.com/discourse/discourse/blob/master/lib/pretty_text.rb
In addition, titles and all other places where non-admins can enter code is protected either using the Handlebars library or standard Rails XSS protection.
In addition, titles and all other places where non-admins can enter code are protected either using the Handlebars library or standard Rails XSS protection.
### CSRF
CSRF allows malicious sites to perform HTTP requests pretending to be an end-user (without their knowledge) more at: http://en.wikipedia.org/wiki/Cross-site_request_forgery
[CSRF](http://en.wikipedia.org/wiki/Cross-site_request_forgery) allows malicious sites to perform HTTP requests pretending to be an end-user (without their knowledge), mostly by getting users who already hold a valid forum login cookie to click a specific link in their web browser.
Discourse extends the built-in Rails CSRF protection in a couple of ways:
Discourse extends the built-in Rails CSRF protection:
1. By default any non GET requests ALWAYS require a valid CSRF token. If a CSRF token is missing Discourse will raise an exception.
@ -40,13 +42,10 @@ Discourse extends the built-in Rails CSRF protection in a couple of ways:
3. Certain pages are "cachable", we do not render the CSRF token (`<meta name='csrf-token' ...`) on any cachable pages. Instead when user's are about to perform the first non GET request they retrieve the token via GET `session/csrf`
###Deployment concerns
### Deployment concerns
Discourse strongly recommend that the various Discourse processes (web server, clockwork, sidekiq) run under a non-elevated account. See our install guide for details.
Discourse strongly recommend that the various Discourse processes (web server, clockwork, sidekiq) run under a non-elevated account. See [our install guide](https://github.com/discourse/discourse/blob/master/docs/INSTALL-ubuntu.md) for details.
###Where should I report security issues?
In order to give the community time to respond and upgrade we strongly urge you report all security issues privately. Please email us at `info@discourse.org` with details and we will respond ASAP.
Security issues ALWAYS take precedence over bug fixes and feature work.
### Where should I report security issues?
In order to give the community time to respond and upgrade we strongly urge you report all security issues privately. Please email us at `team@discourse.org` with details and we will respond ASAP. Security issues *always* take precedence over bug fixes and feature work. We can and do mark releases as "urgent" if they contain serious security fixes.