Security Guidelines

The following guidelines are partly derived from the recommendations of the OWASP Top 10, which lists the ten most critical vulnerabilities of web applications, and the OWASP Top 10 API Security Risks.

Resources

• OWASP Top 10
• OWASP Top 10 API Security Risks

General Guidelines

Before using new libraries:

• Consult with team if library is necessary / if there is already a similar library in use in another part of the project.
• Document decisions in wiki.

Before merging features:

• Audit critical code with Security Engineer.
• Check which security requirements apply and review accordingly.

Cryptography

• Identify sensitive Information (Health Data, Addresses, Location Data).
• Never transmit data in plain. Use HSTS (Used by Spring Security by default).
• Do not store unnecessary data.
• Do not cache sensitive data.
• When storing passwords:
  • Only store hashes
  • Use adaptive salted hash functions with a delay factor to mitigate risk of cracking password hashes using GPUs or rainbow tables.
• Secure setup for cryptography libraries:
  • Don't use standard/weak configuration.
  • Use secure cryptographic algorithms (TODO: team decision).
  • Use strong keys, do not reuse keys.
  • Use strong initialization vectors.
  • Don't use weak modes (for example ECB).
  • Don't use weak/broken hash functions (for example SHA1 or MD5).
  • Don't use deprecated padding methods (for example PKCS number 1 v1.5).
• Don't reveal cryptographic information through error messages.
• Store keys and data separately.
• Never commit keys (also API-keys) to public repository.

Database & Injection

• Always sanitize all user-provided data.
• If possible, use whitelists instead of blacklists.
• Never write code sanitization yourself. Use well-documented, tested libraries. Check with other team members which libraries to use / if there are already libraries included in the project.
• For SQL:
  • Use prepared statements to prevent known injection attacks.
  • Use LIMIT in order to minimize the amount of data adversaries can collect in the case of a successful injection .
• Never store passwords in plain (see Cryptography).
• Don't expose Database port publicly.
• Don't execute database commands as root. Use minimal access rights.
• Don't use standard passwords for Database. Use secure, custom passwords.
• TODO: Discuss with technical team: Security layer in back end through which all data passes.
• Before validating data, bring data to same encoding (e.g. UTF-8 etc.).

Secure Coding

Libraries:

• Audit libraries. Use maintained and well-tested libraries.
• Use libraries instead of writing security-relevant code (sanitization, encryption) yourself.
• Use the same libraries across the project (TODO: team decision).

Exception handling:

• Generally: throw early, catch late.
• Never forward specific errors to the frontend.
  • Users should not be able to read specific logs.
  • Instead, catch error in backend and provide a custom, general error message to the user.

Logging:

• Log files should be confidential.
• Be careful about logging sensitive information. If files contain sensitive I., -> encrypt.
• Log everything, but at least:
  • User Log-in (successful and failed)
  • User Log-out
  • Authorization requests
  • Data-manipulation (CRUD actions)
• Log enough information to identify malicious actors.
• Consistent logging (same framework, same format, TODO: team decision).
• Proper encoding / validation -> prevent log injection attacks (see the OWASP article on Log Injection)

Redirects/SSRF:

• AthleteView should not send requests to other websites (except possibly some well-defined APIs).
• Therefore: use whitelists for allowed domains (Don't use Blacklists/regex for this, since they can be bypassed easily).
  • Otherwise: risk of being abused as a platform for DOS/leaking sensitive data.
• Log all requests originating from the application (also to blocked domains)

Other:

• Consider using static analysis frameworks for critical code (TODO).
• Don't expose any ports that are not needed (e.g. Database).

API-specific

Authorization

• Users should only have access to objects they have permission for.
• Example: /activities/:id should only be accessible if that activity belongs to the trainer/athlete currently logged in.
• Authorization checks in every endpoint that receives an id from the user.
• Don't use predictable IDs for objects.
• Check if users should have access to all properties of the returned objects. (TODO check if we have objects with sensitive properties that should not be returned)
• Check that users of one group have no access to endpoints from another group (e.g. admin endpoints) (TODO: do we have admin endpoints?)

Authentication

• Use a dedicated log-out button.
• Log out user after inactivity.
• Never use standard/weak passwords for admin users (check password against top 10.000 password list).
• Limit repeatedly failing login attempts.
  • Be careful not to create a DoS scenario for legitimate users.
  • Alert admin when brute force attacks are detected.
• Use strong credential recovery techniques (not Question & Answer).
  • recovery through email.
  • When users need to provide their email address for recovery, display the same message in the frontend no matter if the account exists or not to prevent account enumeration attacks.
• Require users to again provide their passwords for sensitive flows (e.g. change email/password)
• Implement weak password checks (see the OWASP password complexity recommendations)

Resource Consumption

• Prevent users from allocating too many resources by limiting size of uploaded pictures (TODO: do we have profile pictures?) and other data (e.g. comment strings, number of comments for an activity)
• Rate-limit the API
  • For example, prevent users from requesting thousands of account recoery emails
  • prevent users from causing the application to call other APIs too often (TODO: will we use other APIs?)

External APIs

• TODO: do we use third-party APIs?
• Do not trust data fetched from other APIs. Threat the data the same way one would treat user input.
• Use TLS for API requests.
• Sanitize data fetched from APIs.
• Don't blindly follow redirects. Use whitelist.