discourse/docs/SECURITY.md

## Discourse Security

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.

### 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.

### 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 64000)

### XSS

The main vector for [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) attacks is via the post composer, as we allow users to enter Markdown, HTML (a safe subset thereof), and BBCode to format posts.

There are 2 main scenarios we protect against:

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.** To protect against client side preview XSS, Discourse uses [Google Caja](https://developers.google.com/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).

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](http://en.wikipedia.org/wiki/Cross-site_request_forgery) allows malicious sites to perform HTTP requests in the context of a forum 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 the following ways:

1. By default any non GET requests ALWAYS require a valid CSRF token. If a CSRF token is missing Discourse will raise an exception.

2. API calls using the secret API bypass CSRF checks.

3. Certain pages are "cachable", we do not render the CSRF token (`<meta name='csrf-token' ...`) on any cachable pages. Instead when users are about to perform the first non GET request they retrieve the token just in time via `GET session/csrf`

### Deployment concerns

We strongly recommend that the various Discourse processes (web server, sidekiq) run under a non-elevated account. See [our install guide](https://github.com/discourse/discourse/blob/master/docs/INSTALL.md) for details.
move security reporting up to the top 2013-07-31 04:59:30 +08:00			`## Discourse Security`
cross-links and copyedits 2013-07-31 04:57:15 +08:00
Replace Clockwork with Sidetiq 2013-08-08 01:25:05 +08:00			`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.`
cross-links and copyedits 2013-07-31 04:57:15 +08:00
copyedits 2013-07-31 05:00:37 +08:00			`### 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.
initial draft of security document 2013-07-29 14:25:28 +08:00
move security reporting up to the top 2013-07-31 04:59:30 +08:00			`### Password Storage`
initial draft of security document 2013-07-29 14:25:28 +08:00
cross-links and copyedits 2013-07-31 04:57:15 +08:00			`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).`
initial draft of security document 2013-07-29 14:25:28 +08:00
			`options you can customise in your production.rb file`

Replace Clockwork with Sidetiq 2013-08-08 01:25:05 +08:00			- `pbkdf2_algorithm`: the hashing algorithm used (default "sha256")
cross-links and copyedits 2013-07-31 04:57:15 +08:00			- `pbkdf2_iterations`: the number of iterations to run (default 64000)
initial draft of security document 2013-07-29 14:25:28 +08:00
			`### XSS`

more security doc copyedits 2013-07-31 05:08:15 +08:00			`The main vector for [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) attacks is via the post composer, as we allow users to enter Markdown, HTML (a safe subset thereof), and BBCode to format posts.`
initial draft of security document 2013-07-29 14:25:28 +08:00
cross-links and copyedits 2013-07-31 04:57:15 +08:00			`There are 2 main scenarios we protect against:`
initial draft of security document 2013-07-29 14:25:28 +08:00
more security doc copyedits 2013-07-31 05:08:15 +08:00			`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.`
initial draft of security document 2013-07-29 14:25:28 +08:00
more security doc copyedits 2013-07-31 05:08:15 +08:00			`2. Markdown displayed on the page invokes an XSS. To protect against client side preview XSS, Discourse uses [Google Caja](https://developers.google.com/caja/) in the preview window.`
initial draft of security document 2013-07-29 14:25:28 +08:00
Replace Clockwork with Sidetiq 2013-08-08 01:25:05 +08:00			`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).`
initial draft of security document 2013-07-29 14:25:28 +08:00
cross-links and copyedits 2013-07-31 04:57:15 +08:00			`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.`
initial draft of security document 2013-07-29 14:25:28 +08:00
			`### CSRF`

move security reporting up to the top 2013-07-31 04:59:30 +08:00			`[CSRF](http://en.wikipedia.org/wiki/Cross-site_request_forgery) allows malicious sites to perform HTTP requests in the context of a forum 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.`
initial draft of security document 2013-07-29 14:25:28 +08:00
move security reporting up to the top 2013-07-31 04:59:30 +08:00			`Discourse extends the built-in Rails CSRF protection in the following ways:`
initial draft of security document 2013-07-29 14:25:28 +08:00
			`1. By default any non GET requests ALWAYS require a valid CSRF token. If a CSRF token is missing Discourse will raise an exception.`

move security reporting up to the top 2013-07-31 04:59:30 +08:00			`2. API calls using the secret API bypass CSRF checks.`
initial draft of security document 2013-07-29 14:25:28 +08:00
move security reporting up to the top 2013-07-31 04:59:30 +08:00			3. Certain pages are "cachable", we do not render the CSRF token (`<meta name='csrf-token' ...`) on any cachable pages. Instead when users are about to perform the first non GET request they retrieve the token just in time via `GET session/csrf`
initial draft of security document 2013-07-29 14:25:28 +08:00
cross-links and copyedits 2013-07-31 04:57:15 +08:00			`### Deployment concerns`
initial draft of security document 2013-07-29 14:25:28 +08:00
Update install guide link 2014-04-25 22:52:36 +08:00			`We strongly recommend that the various Discourse processes (web server, sidekiq) run under a non-elevated account. See [our install guide](https://github.com/discourse/discourse/blob/master/docs/INSTALL.md) for details.`