Security/Kuma2
Item Reviewed
Kuma 2.0 | |
Target |
|
{{#set:SecReview name=Kuma 2.0
|SecReview target=
- https://kuma-stage.mozilla.org/
- SecReview Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=662860
- KumaScript diagram: https://github.com/mozilla/kumascript/
- Product Backlog: https://bugzilla.mozilla.org/showdependencytree.cgi?id=710713&hide_resolved=1
}}
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?
- Existing solution is MindTouch (reason for migration to django)
- very shaky PHP & Mono on Linux
- lots of security holes including a bunch that we find ourselves (https://bugzilla.mozilla.org/buglist.cgi?list_id=2969700;status_whiteboard_type=allwordssubstr;product=Mozilla%20Developer%20Network;status_whiteboard=[ws%3Ahigh];query_format=advanced)
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)
- very shaky PHP & Mono on Linux
- lots of security holes including a bunch that we find ourselves (https://bugzilla.mozilla.org/buglist.cgi?list_id=2969700;status_whiteboard_type=allwordssubstr;product=Mozilla%20Developer%20Network;status_whiteboard=[ws%3Ahigh];query_format=advanced)
|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)
|
{{#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: