Discoverable list of security tradeoffs

[jskinne3]

An experiment

Hypothesis: if we list the security assumptions and tradoffs that cause the most confusion in bug reports, we will get fewer false positive bug reports from both human and LLM bughunters. We'd detail both the design decision ("all journalists can see all submissions") and the consequences ("we do not validate reply_uuid belongs to source_uuid").

We could list them in:

• Bugcrowd, our bug bounty program
• Code comments, starting with Provide inline documentation/explanations for common false positive security reports #7899
• Plan text (or markdown) directly in our codebase, possibly located in
  • Individual ADRs
  • AGENTS.md
  • SECURITY.md

The plan:

• First, list top 5-10 of our hottest false positives
• Put the list into Bugcrowd ineligible submissions
• Determine where (and if?) to transfer a similar list (maybe with more details) to the codebase
• Put the list in place; include links to related material like github issues and code
• See if false positive reports go down, developer comprehension goes up

[ChumOfChance]

Here is the shortlist of the top 10 false positive submissions we get to Bugcrowd. I've included the relevant public GitHub issues where I could find one.

Name	Repo	Description	GitHub issue	Count (approx)
Flask Session Cookie	securedrop	The flask session cookie “discloses” the source codename/passphrase	#204	50
IDOR Confusion	securedrop	Any journalist/admin can interact with any submission/source. As such, there is no validation in the API on a number of IDOR related things.	#7820 , #1355 ,	35
Malicious Server Key Swap	securedrop-client	A malicious server can swap a source’s key and the client will accept it. This would not normally happen, except in the case of a compromised server which is already gameover.	freedomofpress/securedrop-client#2955	12
TOTP Burn	securedrop	The auth flow for journalists checks the TOTP 2FA code before validating the password. If an attacker knows a journalist’s username + 2FA (but not password) they can block a journalist from logging in for 30 seconds.		12
Creds in dom0	securedrop-workstation	The Submission Private Key exists in dom0 with “world-readable” permissions (644) in dom0. Dom0 is a trusted domain, the most trusted in Qubes.		8
2FA Code in Logs	securedrop	On successful login, a journalist’s valid TOTP code is logged. It would be valid for 30 seconds.		7
2FA Shared Secret in Logs	securedrop	If a validation error is triggered by a journalist user, the shared HOTP secret shows up in the application server logs. This could be an issue if shared with us		6
2FA Reset Session	securedrop	Upon a 2fa reset (by a journalist or admin) the current sessions/API tokens are not immediately expired		5
2FA Reset Re-auth	securedrop	Resetting a Journalist 2FA does not re-prompt for the password/current 2FA, which is a common practice.		5