1049733 - SecReview: Mozillians.org

Status: REOPENED

(mozilla.org :: Security Assurance: Applications, task)

Description

[William Reynolds [:williamr]]

We would like to do a general security review of mozillians.org. A few features of the site have had security reviews, though we have not recent done a general review in the last 2 years.

Comment 1

[Julien Vehent]

We were just talking about doing a rapid risk assessment [1] of Mozillians to understand how its database of vouched mozillians is used for access control.

:curtisk - could you schedule a 30m RRA for next week or the week after?

[1] https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=37684270&src=search

Comment 2

[William Reynolds [:williamr]]

(In reply to Julien Vehent [:ulfr] from comment #1)
> We were just talking about doing a rapid risk assessment [1] of Mozillians
> to understand how its database of vouched mozillians is used for access
> control.

A vouched Mozillian gets this additional access:
https://wiki.mozilla.org/Mozillians/Vouching#What_does_.22being_vouched.22_mean.3F

Also, membership in a group *can* be used for access control. The Monthly Internal Call on Air Mozilla is visible to volunteers in the 'nda' group and those with a paid staff email address. Membership in the group requires approval by the group curator.

https://mozillians.org/group/nda

Comment 3

[Julien Vehent]

RRA ran today: https://docs.google.com/a/mozilla.com/spreadsheets/d/158cKK5gRgSGbq503WHAsHOM6dQsm5FozOldQJuUU41o/edit#gid=1112083357

From an OpSec perspective, the recommendation is to run Mozillians.org on dedicated systems and considering using TCW to push releases. The fact that several services rely on the mozillians.org API for access control augments the availability requirement of the service.

From an AppSec perspective, the recommendation is to pentest and audit sensitive areas of the code, and to flag those areas to run recurring checks upon modifications.

Comment 4

[William Reynolds [:williamr]]

Adding some previous security review bugs for mozillians.org

Comment 5

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

The work here appears to have been completed, so I am closing this bug. For the appsec portions of code that need review set the "sec-review" flag to "?" and we'll get a resource assigned to review those code bits.

Comment 6

[Julien Vehent]

:curtis - William asked for a code review of the current code, which afaik has not been reviewed after the latest changes. I'll reopen. Please link to the review finding bugs if one exist, so we can close this bug.

Comment 7

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Code reviews don't work that way, like traditional code reviews you put a "?" for the reviewer (in our case the sec-review flag) and since there is not module owner for it we assign someone with the appropriate skills. If we find an issue it's either noted in the bug itself or a blocking security hidden bug is filled (depends on severity and the issue).

As noted in comment 3
>From an AppSec perspective, the recommendation is to pentest and audit sensitive areas of the code, and to >flag those areas to run recurring checks upon modifications.

Since this will be pointed areas of the code having a general security review bug open that is normally for group reviews seems unnecessary.

Comment 8

[Julien Vehent]

:williamr - could you create a separate bug to review the areas of the code that are sensitive? I'm guessing that verifying user membership to a group would be a good start.