diff --git a/docs/SECURITY.md b/docs/SECURITY.md index bb101b338..3c59b4d69 100644 --- a/docs/SECURITY.md +++ b/docs/SECURITY.md @@ -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 (`