If I am reading this correctly, I'm a little surprised that Dropbox is sending their security problems through another company's (Slack's) chat system.
I think that once you make then decision to use another companies chat system, you have to recognize that just about any information might end up on it.
I can't imagine trying to educate users (outside of an environment in which this thinking is normal) about what can and cannot go over which medium.
The realtime(ish) notifications and questions that they describe in the blog post seem relatively benign compared to say, product planning discussions.
Disclaimer: I used to work at Dropbox and know the individuals involved
The sql executes they are using build queries with "%s" instead of using ? parameters. I guess they foresee that those scripts only see friendly data but it's better to be safe than sorry and protect against sql injection from day 1.
I work on the security engineering team at Dropbox, and help manage our open source programmes.
Note that we aren't doing ``.format()`` or ``%``, but passing the fill text as the second parameter to ``.execute()`` — this is the correct way to protect against SQLi using MySQLdb.
I actually mistakenly thought this was SQLi when I was reviewing this code for release. Unfortunately, the MySQLdb documentation doesn't make that obvious.
This is very interesting. I worked on a similar project, but somewhat different. It's a Slack bot that monitors your Slack channels for indicators (IPs, URLs, files, etc.) and alerts you to possible threats, such as phishing attacks. Your Slack channel is as good an attack vector as anything else.
Ideally you can practice immutable infrastructure and avoid running any ad-hoc commands on non-dev systems. Especially administrative ones using sudo. Takes a bit of a culture shift though if people aren't used to working that way.
Ideally you implement a middle ground of declarative (but not necessarily immutable) infrastructure where changes are diffed. Terraform does this pretty nicely.
I hear what you're saying, but we've got elastic search in Terraform as a module, and you dare not make mods to an existing cluster; Terraform will dutifully tear that cluster down depending on the changes you make (I mean, sure, use a "plan" first, but still).
Which is my way of saying that those automatic queries will likely start to annoy folks very soon, and they'll find a way not to deal with them.