Skip to content

Latest commit

 

History

History
33 lines (23 loc) · 3.46 KB

owasp-top-10.md

File metadata and controls

33 lines (23 loc) · 3.46 KB

OWASP Top 10

The Fleet community follows best practices when coding. Here are some of the ways we mitigate against the OWASP top 10 issues:

Describe your secure coding practices, including code reviews, use of static/dynamic security testing tools, 3rd party scans/reviews.

  • Every piece of code that is merged into Fleet is reviewed by at least one other engineer before merging. We don't use any security-specific testing tools.
  • The server backend is built in Golang, which (besides for language-level vulnerabilities) eliminates buffer overflow and other memory related attacks.
  • We use standard library cryptography wherever possible, and all cryptography is using well-known standards.

SQL Injection

  • All queries are parameterized with MySQL placeholders, so MySQL itself guards against SQL injection and the Fleet code does not need to perform any escaping.

Broken authentication – authentication, session management flaws that compromise passwords, keys, session tokens etc.

Passwords

  • Fleet supports SAML auth which means that it can be configured such that it never sees passwords.
  • Passwords are never stored in plaintext in the database. We store a bcrypted hash of the password along with a randomly generated salt. The bcrypt iteration count and salt key size are admin-configurable.

Authentication tokens

Sensitive data exposure – encryption in transit, at rest, improperly implemented APIs.

  • By default, all traffic between user clients (such as the web browser and fleetctl) and the Fleet server is encrypted with TLS. By default, all traffic between osqueryd clients and the Fleet server is encrypted with TLS. Fleet does not encrypt any data at rest (however a user could separately configure encryption for the MySQL database and logs that Fleet writes).

Broken access controls – how restrictions on what authorized users are allowed to do/access are enforced.

Cross-site scripting – ensure an attacker can’t execute scripts in the user’s browser

  • We render the frontend with React and benefit from built-in XSS protection in React's rendering. This is not sufficient to prevent all XSS, so we also follow additional best practices as discussed in https://stackoverflow.com/a/51852579/491710.

Components with known vulnerabilities – prevent the use of libraries, frameworks, other software with existing vulnerabilities.

  • We rely on Github's automated vulnerability checks, community news, and direct reports to discover vulnerabilities in our dependencies. We endeavor to fix these immediately and would almost always do so within a week of a report.