Security/Reviews/TreeHerder
From MozillaWiki
Please use "Edit with form" above to edit this page.
Item Reviewed
TreeHerder | |||||||||
Target |
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%); |
The given value "
ID | Summary | Priority | Status |
---|---|---|---|
971467 | Treeherder Security Review | P1 | RESOLVED |
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);
" contains strip markers and therefore it cannot be parsed sufficiently.Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- 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
What solutions/approaches were considered other than the proposed solution?
`
Why was this solution chosen?
`
Any security threats already considered in the design and why?
`
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
- Property "SecReview feature goal" (as page type) with input value "* 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" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview threat brainstorming" (as page type) with input value "* 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?
Action Items
Action Item Status | None |
Release Target | ` |
Action Items | |
' |