From 76591eaee2aad50dfd848dcae4106f4648e721f8 Mon Sep 17 00:00:00 2001 From: Zachary Wasserman Date: Wed, 16 Jan 2019 12:50:50 -0800 Subject: [PATCH] Add documentation on OWASP Top 10 (#1991) Thanks to @benbasscom who interviewed me and put together this document. Closes #1951 --- docs/infrastructure/README.md | 4 ++++ docs/infrastructure/owasp-top-10.md | 33 +++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+) create mode 100644 docs/infrastructure/owasp-top-10.md diff --git a/docs/infrastructure/README.md b/docs/infrastructure/README.md index baaeb1cf8b..1f730d1d2e 100644 --- a/docs/infrastructure/README.md +++ b/docs/infrastructure/README.md @@ -22,3 +22,7 @@ For more information, you can also read the [Configuring The Fleet Binary](./con ## Working with osquery logs Fleet allows users to schedule queries, curate packs, and generate a lot of osquery logs. For more information on how you can access these logs as well as examples on what you can do with them, see the [Working With Osquery Logs](./working-with-osquery-logs.md) documentation. + +## Security + +Fleet developers have documented how Fleet handles the [OWASP Top 10](./owasp-top-10.md). diff --git a/docs/infrastructure/owasp-top-10.md b/docs/infrastructure/owasp-top-10.md new file mode 100644 index 0000000000..06e1cdd223 --- /dev/null +++ b/docs/infrastructure/owasp-top-10.md @@ -0,0 +1,33 @@ +# 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 `bcrypt`ed hash of the password along with a randomly generated salt. The `bcrypt` iteration count and salt key size are admin-configurable. +#### Authentication tokens +- The size and expiration time of session tokens is admin-configurable. See [https://github.com/kolide/fleet/blob/master/docs/infrastructure/configuring-the-fleet-binary.md#session_duration](https://github.com/kolide/fleet/blob/master/docs/infrastructure/configuring-the-fleet-binary.md#session_duration). +- It is possible to revoke all session tokens for a user by forcing a password reset. + + +### 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. +- Each session is associated with a viewer context that is used to determine the access granted to that user. Access controls can easily be applied as middleware in the routing table, so the access to a route is clearly defined in the same place where the route is attached to the server see [https://github.com/kolide/fleet/blob/master/server/service/handler.go#L114-L189](https://github.com/kolide/fleet/blob/master/server/service/handler.go#L114-L189). + +### 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](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.