- Threat:
whodunnit
Spoofing via Direct Database Manipulation- Description: An attacker with direct write access to the
versions
table (e.g., through a compromised database account or a separate SQL injection vulnerability) directly modifies thewhodunnit
column to attribute changes to a different user. - Impact: False attribution of actions, undermining audit trail integrity and potentially framing innocent users. Loss of accountability.
- Affected Component:
versions
table (whodunnit
column), PaperTrail's core versioning mechanism. - Risk Severity: High
- Mitigation Strategies:
- Database Security: Implement strict least-privilege access control on the database. Ensure database users have only the necessary permissions.
- Database Auditing: Enable database-level auditing to track all changes to the
versions
table, including the source of the changes (IP address, user, etc.).
- Description: An attacker with direct write access to the
- Threat:
whodunnit
Spoofing via Application Code Manipulation- Description: An attacker who can modify the application code (e.g., through a compromised server or a code injection vulnerability) alters the logic that sets the
whodunnit
value, causing it to record incorrect user information. - Impact: Similar to direct database manipulation, this leads to false attribution of actions and undermines the audit trail.
- Affected Component:
PaperTrail::VersionConcern#user_for_paper_trail
(or the custom method used to setwhodunnit
), PaperTrail's configuration. - Risk Severity: High
- Mitigation Strategies:
- Code Integrity: Implement strong code integrity controls to prevent unauthorized code modifications (e.g., code signing, file integrity monitoring).
- Externalize
whodunnit
: Consider using an external, trusted service (e.g., an authentication provider) to determine thewhodunnit
value, making it harder to spoof.
- Description: An attacker who can modify the application code (e.g., through a compromised server or a code injection vulnerability) alters the logic that sets the
- Threat: Direct Deletion of Version Records
- Description: An attacker with direct database access deletes records from the
versions
table, removing the history of specific changes. - Impact: Loss of audit trail data, making it impossible to track past actions or revert to previous states. Potential for data loss if the application relies on version history for functionality.
- Affected Component:
versions
table, PaperTrail's core versioning mechanism. - Risk Severity: High
- Mitigation Strategies:
- Database Security: Strict least-privilege access control on the database.
- Database Auditing: Enable database-level auditing.
- Database Backups: Implement regular, secure database backups and test the restoration process.
- Row-Level Security (RLS): If supported by the database, use RLS.
- Description: An attacker with direct database access deletes records from the
- Threat: Modification of Serialized
object
Data- Description: An attacker with direct database access modifies the serialized data in the
object
column of theversions
table, potentially injecting malicious code or altering historical data. - Impact: If the application deserializes and uses this modified data without proper validation, it could lead to code execution, data corruption, or other security vulnerabilities.
- Affected Component:
versions
table (object
column), PaperTrail's serialization mechanism. - Risk Severity: Critical (if deserialization is unsafe), High (if data is used without validation)
- Mitigation Strategies:
- Safe Deserialization: Use a safe deserialization library and whitelist allowed classes. Never use unsafe deserialization methods like
Marshal.load
with untrusted data. - Input Validation: Thoroughly validate and sanitize any data retrieved from the
object
column before using it. - Data Encryption: Consider encrypting the
object
data at rest. - Database Security: Strict least-privilege access control on the database.
- Safe Deserialization: Use a safe deserialization library and whitelist allowed classes. Never use unsafe deserialization methods like
- Description: An attacker with direct database access modifies the serialized data in the
- Threat: Modification of
object_changes
- Description: Similar to modifying
object
, but targeting theobject_changes
column. - Impact: Can lead to incorrect display of changes, or potential vulnerabilities if the application uses this data unsafely.
- Affected Component:
versions
table (object_changes
column). - Risk Severity: High
- Mitigation Strategies: Same as for
object
modification.
- Description: Similar to modifying
- Threat: Versioning Temporarily Disabled
- Description: Versioning is accidentally or maliciously disabled (e.g., by commenting out code, changing configuration) for a period, resulting in a gap in the audit trail.
- Impact: Loss of audit trail data for the period when versioning was disabled.
- Affected Component: PaperTrail configuration,
PaperTrail.enabled = false
, model-levelhas_paper_trail
declaration. - Risk Severity: High
- Mitigation Strategies:
- Configuration Management: Use a robust configuration management system.
- Code Review: Require code reviews for any changes that could affect PaperTrail's configuration.
- Monitoring: Implement monitoring to detect if PaperTrail is disabled.
- Alerting: Set up alerts to notify administrators if PaperTrail is disabled.
- Threat: Unauthorized Access to Version History via UI/API
- Description: The application's user interface or API allows unauthorized users to view the version history of records, exposing potentially sensitive information. This is directly related to PaperTrail because it's the version history that's being exposed.
- Impact: Leakage of sensitive data.
- Affected Component: Application controllers and views that display version history, PaperTrail's
version
association. - Risk Severity: High
- Mitigation Strategies:
- Authorization Checks: Implement strict authorization checks.
- API Security: Carefully review API endpoints.
- Threat: Sensitive Data Stored in
object
orobject_changes
- Description: Sensitive data (e.g., passwords, API keys, PII) is stored directly in the
object
orobject_changes
columns without encryption or redaction. - Impact: Exposure of sensitive data if the
versions
table is compromised. - Affected Component:
versions
table (object
andobject_changes
columns), PaperTrail's serialization mechanism. - Risk Severity: Critical
- Mitigation Strategies:
- Data Minimization: Avoid storing sensitive data in versioned fields.
- Data Redaction/Anonymization: Redact or anonymize sensitive data.
- Field-Level Encryption: Encrypt sensitive fields.
ignore
,only
,skip
Options: Use PaperTrail's options to exclude specific attributes.
- Description: Sensitive data (e.g., passwords, API keys, PII) is stored directly in the