In the development process of WorkAround, we try to implement a as secure system as possible.
Users can create weak passwords for their authentication.
Protection:
- Users can't create passwords shorter than 12 characters.
Action:
- Inform users to use a strong password when they try use a weak one.
The session created after a user login has no reasonable timeout duration.
Protection:
- Sessions timeout after 1 hour.
An attacker could inject malicious SQL statements to retrieve sensitive data.
Protection:
- Use of client library to not directly write SQL statements (ORM-like behavior).
Detection:
- Regular checks of logs
Action:
-
Revert malicious changes
-
Inform users if sensitive data got stolen or publicly available.
Dependencies used by the application are vulnerable for misuse by an attacker.
Protection:
- Use of only the most recent/secure versions possible (Sometimes not possible due to peer dependencies).
Detection:
- GitHub Dependabot alerts when a dependency has known security vulnerabilities.
Action:
- Update vulnerable dependencies to secure version.
Secrets are stored in plain text in VCS or can be read by malicious processes, like CI/CD.
Protection:
-
Secrets aren't stored in the VCS.
-
CI/CD Pipelines can just access repository secrets through an authorized user.
-
CI/CD Pipelines can't expose secrets through GitHubs policies.
-
Forks don't have access to repository secrets.
Error messages give too much information about the business logic of an application which can be used by an attacker.
Protection:
-
Error messages shown to the user do not expose business logic which could help to attack the system.
-
Auth related error message don't expose if the email or the password was wrong at a login try.
User can access data they should have no access to.
Protection:
- Through the use of Postgres Policies users can't access data they should not access.
Detection:
OPEN: Log database actions
Action:
- Inform users if sensitive data got stolen or publicly available.
An attacker could implement an iframe with the application on another website to hijack users credentials or to perform actions in their names.
Protection:
- Through the Content-Security-Policy directive
frame-ancestors 'none';the application can't be embedded in another website.
An attacker can inject malicious code through a loosely configured CSP.
Protection:
WIP: A deny-by-default policy restricts executable sources to a minimum.