Our comms team told us we need an image; our legal team told us it needed to be freely licensed. Credit: Carsten Schertzer (Creative Commons Attribution 2.0)
Dropbox employs traditional cross-site attack defenses, but we also employ same-site cookies as a defense in depth on newer browsers. In this post, we describe how we rolled out same-site cookie based defenses on Dropbox, and offer some guidelines on how you can do the same on your website.
Recently, the IETF released a new RFC introducing same-site cookies.
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
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.
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.
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.
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