Security/Kuma2

From MozillaWiki
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Item Reviewed

Kuma 2.0
Target

{{#set:SecReview name=Kuma 2.0

|SecReview target=

}}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

  • There aren't just one or two new features: The effort is rebuilding the entire MDN content management platform almost from scratch, in order to replace the MindTouch product we've been using.
  • Question: Does the project team (Les & Luke) need to first build up an inventory of discrete features and review them in turn?
  • Some new and reworked features include the following (this is not a complete list)
    • Raw HTML content editing, with CKeditor for WYSIWYG and Bleach white-lists for markup sanitation
    • Macros powered by server-side JavaScript, written by trusted wiki editors, the output of which is also sanitized with Bleach. (ie. KumaScript)
    • File uploads for page attachments
    • L10n in page content
    • Content migration from MindTouch to Kuma

What solutions/approaches were considered other than the proposed solution?

Why was this solution chosen?

  • inherits standard django code that powers support.mozilla.org so we can leverage Webdev efforts
  • django platform more widespread than

Any security threats already considered in the design and why?

  • using bleach for html sanitzation
  • upload file scanning

Threat Brainstorming

  • Some of the new features could have technical security issues:
    • Raw HTML Editing
    • Server-side JS
    • File uploads
    • Code samples in wiki
  • While these features are for trusted editors etc, they may be subject to CSRF, authorization bypass, etc flaws, and/or have security issues which could affect the underlying system.

{{#set: SecReview feature goal=* There aren't just one or two new features: The effort is rebuilding the entire MDN content management platform almost from scratch, in order to replace the MindTouch product we've been using.

  • Question: Does the project team (Les & Luke) need to first build up an inventory of discrete features and review them in turn?
  • Some new and reworked features include the following (this is not a complete list)
    • Raw HTML content editing, with CKeditor for WYSIWYG and Bleach white-lists for markup sanitation
    • Macros powered by server-side JavaScript, written by trusted wiki editors, the output of which is also sanitized with Bleach. (ie. KumaScript)
    • File uploads for page attachments
    • L10n in page content
    • Content migration from MindTouch to Kuma

|SecReview alt solutions=* Existing solution is MindTouch (reason for migration to django)

|SecReview solution chosen=* inherits standard django code that powers support.mozilla.org so we can leverage Webdev efforts

  • django platform more widespread than

|SecReview threats considered=* using bleach for html sanitzation

  • upload file scanning

|SecReview threat brainstorming=* Some of the new features could have technical security issues:

    • Raw HTML Editing
    • Server-side JS
    • File uploads
    • Code samples in wiki
  • While these features are for trusted editors etc, they may be subject to CSRF, authorization bypass, etc flaws, and/or have security issues which could affect the underlying system.

}}

Action Items

Action Item Status In Progress
Release Target `
Action Items
* Who :: What :: By when (Keep in mind all these things will be bugs that block the reivew bug, that blocks the feature bug)
  • adamm :: reveiw list of bleached whitelist items :: before launch
  • adamm :: Diagram overall architecture, build high-level architecture  :: asap
    • Identify existing areas of known tech debt  :: asap
    • adamm :: Review architecture, identify areas of architectural risk  :: asap
  • adamm :: Identify defensive approaches defined by the project for handling expected types of bugs (injection, output encoding, csrf, etc)  :: asap
    • code-review areas identified as high-risk
  • adamm :: Identify areas of techical risk which warrant code review
  • adamm :: Black-box test of staging environment

{{#set:|SecReview action item status=In Progress

|Feature version=` |SecReview action items=* Who :: What :: By when (Keep in mind all these things will be bugs that block the reivew bug, that blocks the feature bug)

  • adamm :: reveiw list of bleached whitelist items :: before launch
  • adamm :: Diagram overall architecture, build high-level architecture  :: asap
    • Identify existing areas of known tech debt  :: asap
    • adamm :: Review architecture, identify areas of architectural risk  :: asap
  • adamm :: Identify defensive approaches defined by the project for handling expected types of bugs (injection, output encoding, csrf, etc)  :: asap
    • code-review areas identified as high-risk
  • adamm :: Identify areas of techical risk which warrant code review
  • adamm :: Black-box test of staging environment

}} Required Reading List:

Retrieved from "https://wiki.allizom.org/index.php?title=Security/Kuma2&oldid=424762"