Security/Kuma2

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
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: