<commit_before>Attacks and Countermeasures on the SecureDrop Environment  
=========================================================

SecureDrop is a complex ecosystem comprised of various pieces of hardware, a
diverse codebase, multiple user roles, and varied software dependencies. As
such, an adversary can compromise any one of these components through a variety
of attacks, as detailed below. We’ve categorized attacks and countermeasures by
SecureDrop architecture area for clarity.

There are certain attacks that cannot be mitigated by any of the technical or
operational countermeasures built into SecureDrop. Attacks of a political nature
— for example, if a source, journalist, or organization is threatened with legal
action — are context-dependent, and determined by an ever-shifting climate
around press freedoms. While these attack vectors are out of the scope of this
document, they should be factored in to any organization’s threat model with
regional and political specificity.

Application Code — SecureDrop Repository/Release
------------------------------------------------

Attacks to the Application Code — SecureDrop Respository/Release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  Malicious code introduced in SecureDrop repository
-  Malicious code introduced in SecureDrop release
-  Failure to encrypt submissions as they are written to disk

Countermeasures on the Application Code — SecureDrop Repository/Release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  Code (git tags) and releases (packages uploaded to apt) are signed with the airgapped signing key
-  Protection is placed on master and develop branch on GitHub
-  For SecureDrop Developers, 2-factor authentication is mandated on GitHub
-  Community trust is built through 3 trusted code owners and code reviews

Application Code — *Source Interface* and *Journalist Interface*
----------------------------------------------------------------

Attacks to the Application Code — *Source Interface* and *Journalist Interface*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  Configuration vulnerability in *Source* or *Journalist Interface*
-  Lack of segmentation between *Source* and *Journalist Interface*
-  Session management vulnerability in *Source* or *Journalist Interface*
-  Malicious input vulnerability in *Source* or *Journalist Interface*
-  Configuration  vulnerability in *Source* or *Journalist Interface*
-  Authentication vulnerability in *Source* or *Journalist Interface*
-  Access control vulnerability in *Source* or *Journalist Interface*
-  Data protection vulnerability in *Source* or *Journalist Interface*
-  Communications vulnerability in *Source* or *Journalist Interface*
-  Error handling and logging vulnerability in *Source* or *Journalist Interface*
-  HTTP security configuration vulnerability in *Source* or *Journalist Interface*
-  File and resource vulnerability in *Source* or *Journalist Interface*
-  Business logic vulnerability in *Source* or *Journalist Interface*
-  Web services vulnerability in *Source* or *Journalist Interface*

Countermeasures on both *Source* and *Journalist Interfaces*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  *Interfaces* run on an end-to-end encrypted Tor hidden service
-  Sensitive source and submission data is sent through HTTP POST
-  All source submissions are encrypted with GPG at rest using the airgapped submission key
-  *Interface* sessions are invalidated after a user logs out or inactivity over 120 minutes
-  Session control on *Interface* includes CSRF token in Flask Framework
-  All *Interface* session data (except language and locale selection) is discarded at logout, and fully deleted upon exiting the Tor Browser
-  A number of mitigations are in place as protection against malicious input vulnerabilities on the Source and Journalist Interfaces:

    - X-XSS-PROTECTION is enabled
    - Content-Security-Policy is set to self
    - SQLAlchemy is used as ORM for all database queries
    - Application does not execute uploaded submission data
-  A number of mitigations are in place as protection against the risk of an HTTP misconfiguration on the *Source* and *Journalist Interfaces*:

    - Cache control header is set to “no store;”
    - Only HTTP GET, POST and HEAD are allowed
    - HTTP headers do not expose version information of system components
    - X-Content-Type is set to "nosniff;"
    - Content-Security-Policy is set to "self;"
    - X-XSS-Protection is set to "1"

Countermeasures unique to *Source Interface*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  TLS on *Source Interface* is opt-in with an EV cert
-  A number of mitigations are in place as protection against access control vulnerabilities on the *Source Interface*:

    - Source codenames are long and automatically generated
    - Hashed codenames are stored in a database hashed with a unique salt
    - Source codename reset functionality is not available
    - Source login does not display information about prior submissions
    - Source login requires 7-word codename to check *Source Interface* for replies

Countermeasures unique to *Journalist Interface*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  *Journalist Interface* is located behind an authenticated hidden service and only privileged users have required authorization token
-  A number of mitigations are in place as protection against access control vulnerabilities on the *Journalist Interface*:

    - Apache autoindex module is disabled
    - Journalist/Admin passphrases are long and automatically generated
    - Passphrases are stored in a database hashed with a unique salt
    - Account generation/revocation/reset is restricted to Admin role
    - Two-factor authentication is required through a TOTP token or a Yubikey

*Application Server* and *Monitor Server*
-----------------------------------------

Attacks on the *Application Server* and *Monitor Server*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  *Application* or *Monitor Server* configuration error
-  *Source* or *Journalist Interface* is framed
-  *Application* or *Monitor Server* is compromised
-  Attacker exploits postfix
-  Known vulnerabilities in the Linux kernel or packages used by app/mon servers

Countermeasures on Both *Application* and *Monitor Servers*<commit_msg>Docs - DELETE method allowed on journalist interface for API<commit_after>Attacks and Countermeasures on the SecureDrop Environment  
=========================================================

SecureDrop is a complex ecosystem comprised of various pieces of hardware, a
diverse codebase, multiple user roles, and varied software dependencies. As
such, an adversary can compromise any one of these components through a variety
of attacks, as detailed below. We’ve categorized attacks and countermeasures by
SecureDrop architecture area for clarity.

There are certain attacks that cannot be mitigated by any of the technical or
operational countermeasures built into SecureDrop. Attacks of a political nature
— for example, if a source, journalist, or organization is threatened with legal
action — are context-dependent, and determined by an ever-shifting climate
around press freedoms. While these attack vectors are out of the scope of this
document, they should be factored in to any organization’s threat model with
regional and political specificity.

Application Code — SecureDrop Repository/Release
------------------------------------------------

Attacks to the Application Code — SecureDrop Respository/Release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  Malicious code introduced in SecureDrop repository
-  Malicious code introduced in SecureDrop release
-  Failure to encrypt submissions as they are written to disk

Countermeasures on the Application Code — SecureDrop Repository/Release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  Code (git tags) and releases (packages uploaded to apt) are signed with the airgapped signing key
-  Protection is placed on master and develop branch on GitHub
-  For SecureDrop Developers, 2-factor authentication is mandated on GitHub
-  Community trust is built through 3 trusted code owners and code reviews

Application Code — *Source Interface* and *Journalist Interface*
----------------------------------------------------------------

Attacks to the Application Code — *Source Interface* and *Journalist Interface*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  Configuration vulnerability in *Source* or *Journalist Interface*
-  Lack of segmentation between *Source* and *Journalist Interface*
-  Session management vulnerability in *Source* or *Journalist Interface*
-  Malicious input vulnerability in *Source* or *Journalist Interface*
-  Configuration  vulnerability in *Source* or *Journalist Interface*
-  Authentication vulnerability in *Source* or *Journalist Interface*
-  Access control vulnerability in *Source* or *Journalist Interface*
-  Data protection vulnerability in *Source* or *Journalist Interface*
-  Communications vulnerability in *Source* or *Journalist Interface*
-  Error handling and logging vulnerability in *Source* or *Journalist Interface*
-  HTTP security configuration vulnerability in *Source* or *Journalist Interface*
-  File and resource vulnerability in *Source* or *Journalist Interface*
-  Business logic vulnerability in *Source* or *Journalist Interface*
-  Web services vulnerability in *Source* or *Journalist Interface*

Countermeasures on both *Source* and *Journalist Interfaces*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  *Interfaces* run on an end-to-end encrypted Tor hidden service
-  Sensitive source and submission data is sent through HTTP POST
-  All source submissions are encrypted with GPG at rest using the airgapped submission key
-  *Interface* sessions are invalidated after a user logs out or inactivity over 120 minutes
-  Session control on *Interface* includes CSRF token in Flask Framework
-  All *Interface* session data (except language and locale selection) is discarded at logout, and fully deleted upon exiting the Tor Browser
-  A number of mitigations are in place as protection against malicious input vulnerabilities on the Source and Journalist Interfaces:

    - X-XSS-PROTECTION is enabled
    - Content-Security-Policy is set to self
    - SQLAlchemy is used as ORM for all database queries
    - Application does not execute uploaded submission data
-  A number of mitigations are in place as protection against the risk of an HTTP misconfiguration on the *Source* and *Journalist Interfaces*:

    - Cache control header is set to “no store;”
    - HTTP headers do not expose version information of system components
    - X-Content-Type is set to "nosniff;"
    - Content-Security-Policy is set to "self;"
    - X-XSS-Protection is set to "1"

Countermeasures unique to *Source Interface*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  TLS on *Source Interface* is opt-in with an EV cert
-  Only HTTP GET, POST and HEAD methods are allowed
-  A number of mitigations are in place as protection against access control vulnerabilities on the *Source Interface*:

    - Source codenames are long and automatically generated
    - Hashed codenames are stored in a database hashed with a unique salt
    - Source codename reset functionality is not available
    - Source login does not display information about prior submissions
    - Source login requires 7-word codename to check *Source Interface* for replies

Countermeasures unique to *Journalist Interface*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  *Journalist Interface* is located behind an authenticated hidden service and only privileged users have required authorization token
-  Only HTTP GET, POST, HEAD and DELETE methods are allowed
-  A number of mitigations are in place as protection against access control vulnerabilities on the *Journalist Interface*:

    - Apache autoindex module is disabled
    - Journalist/Admin passphrases are long and automatically generated
    - Passphrases are stored in a database hashed with a unique salt
    - Account generation/revocation/reset is restricted to Admin role
    - Two-factor authentication is required through a TOTP token or a Yubikey

*Application Server* and *Monitor Server*
-----------------------------------------

Attacks on the *Application Server* and *Monitor Server*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  *Application* or *Monitor Server* configuration error
-  *Source* or *Journalist Interface* is framed
-  *Application* or *Monitor Server* is compromised
-  Attacker exploits postfix
-  Known vulnerabilities in the Linux kernel or packages used by app/mon servers

Countermeasures on Both *Application* and *Monitor Servers*
{'fraction_non_alphanumeric': 0.13675609004008635, 'fraction_numerical': 0.0010792476102374346, 'mean_word_length': 4.329909613804437, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6180604', 'n_tokens_mistral': 3021, 'n_tokens_neox': 2758, 'n_words': 1536}