canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776
edits
Security/Reviews/TreeHerder: Difference between revisions
no edit summary
(Created page with "{{SecReviewInfo |SecReview name=TreeHerder }} {{SecReview}} {{SecReviewActionStatus |SecReview action item status=None }}") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{SecReviewInfo | {{SecReviewInfo | ||
|SecReview name=TreeHerder | |SecReview name=TreeHerder | ||
|SecReview target=<bugzilla> | |||
{ | |||
"id":"971467" | |||
} | |||
</bugzilla> | |||
}} | |||
{{SecReview | |||
|SecReview feature goal=* Treeherder is a replacement of an existing application, Tinderbox Pushlog (https://tbpl.mozilla.org/), used for the display of automated test results for several core mozilla products. Treeherder addresses a variety of limitations in tbpl's data model, web service, and user interface. A summary of those limitations can be found here https://wiki.mozilla.org/Auto-tools/Projects/TBPL2. | |||
* The primary server side use cases for treeherder are to provide a web service interface that allows easy submission of test data. This test data is generated by internal test automation systems (buildbot, jenkins, or any job scheduler) associated with pushing code to a particular repository, for any of mozilla's products. These systems need to scale appropriately and also isolate data from different repositories without the need for co-localization within a database. | |||
* In addition to server side requirements, an extensive list of UI requirements, can be found here https://wiki.mozilla.org/Auto-tools/Projects/Treeherder/Current_TBPL_Feature_List. | |||
* replacement for TBPL | |||
** reporting for automatied testing outcomes | |||
* buildbot | |||
** mainteained by rel-eng for automated tests | |||
* all build systems can submit outcomes | |||
|SecReview threat brainstorming=* Web Service Endpoints | |||
** There are web service endpoints for posting data to. These are an obvious exploit, we implemented 2 legged oauth to secure these (https://github.com/mozilla/treeherder-service/blob/master/treeherder/webapp/api/views.py#L23). Oauth credentials are created for each source code repository that receives test data. Worker applications posting data must authenticate individually with each repository. The client side of the oauth implementation is found here https://github.com/mozilla/treeherder-client/blob/master/thclient/client.py#L663. | |||
* (note: 2-legged oauth skips authorization but that doesn't look like it will be an issue for this usage) | |||
*** To test: oauth authentication implementation for correctness | |||
Test case: can test data be submitted with no or broken authentication? | |||
* There are several operations in the user interface that require data modifications that need to be stored. We used persona to provide login functionality in django and the ui for user authentication. | |||
** (note: this isn't completed yet, or at least isn't on the dev instances) | |||
API UI: | |||
http://treeherder-dev.allizom.org/docs/ | |||
** Another possible exploit is data mangling. Data ingested from the incoming json in some cases is displayed directly in the user interface. We're using angularjs, which provides a built in directive for html sanitization, http://docs.angularjs.org/api/ngSanitize. | |||
* CSP | |||
* SQL Quoting - does it happen on sql placeholders? | |||
https://github.com/mozilla/treeherder-service/blob/master/treeherder/model/derived/jobs.py#L156 | |||
}} | }} | ||
{{SecReviewActionStatus | {{SecReviewActionStatus | ||
|SecReview action item status=None | |SecReview action item status=None | ||
}} | }} | ||