Meet Securitybot: Open Sourcing Automated Security at Scale

Security incidents happen. And when they do, they need to be dealt with—quickly. That’s where detection comes into play. The faster incidents are detected, the faster they can be handed off to the security team and resolved. To make detection as fast as possible, teams are usually aided by monitoring infrastructure that fires off an alert any time something even slightly questionable occurs. These alerts can lead to a deluge of information, making it difficult for engineers to sift through. Even worse, a large number of these alerts are false positives, caused by engineers arbitrarily running sudo -i or nmap.

Read more

How Dropbox securely stores your passwords

It’s universally acknowledged that it’s a bad idea to store plain-text passwords. If a database containing plain-text passwords is compromised, user accounts are in immediate danger. For this reason, as early as 1976, the industry standardized on storing passwords using secure, one-way hashing mechanisms (starting with Unix Crypt). Unfortunately, while this prevents the direct reading of passwords in case of a compromise, all hashing mechanisms necessarily allow attackers to brute force the hash offline, by going through lists of possible passwords, hashing them, and comparing the result. In this context, secure hashing functions like SHA have a critical flaw for password hashing: they are designed to be fast.

Read more

[CSP] Third Party Integrations and Privilege Separation

This is the fourth of four posts on our experience deploying Content Security Policy at Dropbox. If this sort of work interests you, we are hiring! We will also be at AppSec USA this week. Come say hi!

In previous blog posts, we discussed our experience deploying CSP at Dropbox, with a particular focus on the script-src directive that allows us to control script sources. With a locked down script-src whitelist, a nonce source, and mitigations to unsafe-eval, our CSP policy provided strong mitigations against XSS via injection attacks in our web application.

Read more

[CSP] The Unexpected Eval

This is the third of four posts on our experience deploying Content Security Policy at Dropbox. If this sort of work interests you, we are hiring! We will also be at AppSec USA this week. Come say hi!

Previously, we discussed how at Dropbox we have deployed CSP at scale to protect against injection attacks. First, we discussed how we extract signal from violation reports to help create a host whitelist and restrict the sources of code running in our application. We also discussed how nonce sources allow us to mitigate XSS attacks due to content injections.

Read more

[CSP] Unsafe-inline and nonce deployment

This is the second of four posts on our experience deploying Content Security Policy at Dropbox. If this sort of work interests you, we are hiring! We will also be at AppSec USA this week. Come say hi!

In the previous post, we discussed how to filter reports and deploy content source whitelists using CSP for the website. Typically, the most important content sources to whitelist are the source of your code, as defined by the script-src (and the object-src directive). A standard content-security-policy deployment will typically include a list of allowed domains like the main website and trusted CDNs in script-src as well as directives like 'unsafe-inline' and 'unsafe-eval'.

Read more

[CSP] On Reporting and Filtering

This is the first of four posts on our experience deploying Content Security Policy at Dropbox. If this sort of work interests you, we are hiring! We will also be at AppSec USA this week. Come say hi!

At Dropbox, we are big fans of Content Security Policy or CSP. For those not familiar with the specification, I recommend reading Mike West’s excellent introduction to CSP. A quick recap: at its core, CSP is a declarative mechanism to whitelist content sources (such as sources for scripts,

Read more