Access control vulnerability in Journalist interface mitigated
THREAT14
· Mitigated: Controls in place bring the risk down to an acceptable level.
· Defined in catalog.py:259
- Risk
- Medium impact × Low likelihood = 4 medium
- After mitigations
- Medium impact × Low likelihood = 4 medium (unchanged)
Ensure that a journalist cannot access any other functionality (e.g. elevate privileges to admin)
Threat actors: Any
Mitigations
| Mitigation | Status |
|---|---|
| Journalist interface is one big inbox (makes for simple logic) MITIG209 | implemented |
| Only 2 roles in journalist / admin interface MITIG208 | implemented |
| CSRF from Flask used MITIG202 | implemented |
Possible further mitigations
- Use different database users for Source, Journalist interfaces MITIG203 proposed
- Restrict source information to certain journalist accounts MITIG210 proposed
Where it applies
Applies to 1 component in 2 scenarios.
Journalist triage · Journalist Interface
Workstation: reading submissions · Journalist Interface
Notes
Existing mitigations: Journalists can access all submissions on the SecureDrop instance (MITIG209). There are 2 roles on this interface. Admin and Journalist users (MITIG208). Admins can create new Journalist accounts. User authorization is validated server-side. CSRF token in Flask framework (https://flask-wtf.readthedocs.io/en/latest/csrf.html#ajax). (MITIG202). Further mitigations: Create different database users for Journalist and Source interfaces and enforce least-privilege (MITIG203). Offer the ability to restrict access to certain sources for certain journalists (MITIG210). Automated test for mitigation: Yes.
How this threat is matched
Listed for these components. A boundary covers every component inside it.