Security Issues

This document describes which security features were implemented and which would need to implemented should this project continue. See also the security merge request.

Implemented

The following security issues have been resolved:

• Use HSTS header.

  • Added by spring security by default (see the documentation)

• Consistent logging.

  • see this MR

• DoS protection:

  • Rate-limit the API
  • Limit repeatedly failing login attempts:
    • IPs that repeatedly fail login are automatically blocked by the backend (for a limited time)

• Never forward specific errors to the frontend.

  • implemented global exception handler that catches everything not already caught by other handlers and returns http 500.

• sanitize all user-provided data.

  • sanitized all DTOs where user-provided strings are present.
  • prevents XSS attacks since dangerous html tags are filtered in user-provided strings.

• Implement weak password checks.

  • OWASP recommends minimum length 8, which is already implemented (see here)
  • PW strength meter added to frontend, which also gives users recommendations how the password strength could be improved.

• Log enough information to identify malicious actors.

  • logged when users run into rate limiting because of multiple failed login attempts.

• check if caching is deactivated in MongoDB (contains sensitive data).

  • MongoDB does not cache query results (see here)

• Don't use standard passwords for Database. Use secure, custom passwords.

  • changed passwords to randomly generated secure passwords.

• check if there are objects with sensitive properties that should not be returned.

  • password in userDTO: not returned. entity to DTO method sets password to null
  • infos the trainer gets about their athletes are reasonable:
    • name, email, country, zip, dob, height, weight: since these can be assumed to be important for training.
    • activities/fitness: this is the whole point of the application, so it is reasonable for the trainer to see this.
    • health data: Athletes can control via preferences if they want to share their health data with their trainer.

Not Implemented

This section lists features that have not been implemented or that can only be checked in production environments:

• for production:

  • check that db ports are not exposed.
  • Store keys securely: secrets (such as database credentials or the Garmin API key) would be stored using a specialized cloud service (like AWS Secrets Manager). In a Kubernetes environment, the External Secrets Operator could be used to inject the stored secrets into a Kubernetes Secret.
  • create users with custom privileges in docker containers before executing services

• Don't use predictable IDs for objects:

  • use UUIDs instead.
  • See this tutorial.

• Do not trust data fetched from other APIs.

  • Sanitize data fetched from the Garmin API.
  • Don't blindly follow redirects. Use whitelist.

• Changing user data securely:

  • implement change email flow.
  • User should provide password again for sensitive flows (like changing email).

• Don't execute database commands as root. Use minimal access rights.

  • create database users with minimal access rights.

• Prevent users from allocating too many resources by limiting size of uploaded iFit files.

  • can be done by checking length of files in the files array in the handleFileUpload method in ase/athlete_view/domain/activity/controller/ActivityController.kt.

• Implement missing privacy features:

  • Enable users to delete their personal data (such as health data stored in the Mongo database).
  • Enable users to obtain their stored personal data.
  • create Privacy Policy page.