3 ms·

Assuming (no evidence, it's just very common) that this was a SQL Injection, here are some ways to protect yourself: * Use http://en.wikipedia.org/wiki/Databas

by elchief 12y ago

Assuming (no evidence, it's just very common) that this was a SQL Injection, here are some ways to protect yourself: * Use http://en.wikipedia.org/wiki/Database_activity_monitoring http://en.wikipedia.org/wiki/Database_activity_monitoring. If you don't list users on your site and you get a query that would return more than one user record, it's a hacker * Add some http://en.wikipedia.org/wiki/Honeytoken http://en.wikipedia.org/wiki/Honeytoken s to your user table, and sound the alarm if they leave your db * Use Row-Level Security * Database server runs on own box in own network zone * Send logs via write-only account to machine in different network zone. Monitor logs automatically, and have alerts. * Pepper your passwords (HMAC them with a key in an HSM on the web server (then bcrypt). Don't store key in db). https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/ https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-p... * Use a WAF that looks for SQL injections * [Use real database authentication, per user. Not one username for everyone connecting to db. Yes, this is bad for connection pooling]

tracker1 12y ago
I think it depends on the structure of the system... If you separate authentication from profile information, then you can run each on separate systems. They were already using bcrypt, which is a fairly strong salted hashing system. As to restricting access, having all access to the database restricted to API servers that provide the limitations you mention, you get a similar level of control, without the complexity of managing per-user database logins. With per-user database logins, you are then subject to whatever system the dbms uses. If you are using systems with looser less fine grained controls, you can be even more limited.
azinman2 12y ago
Why would you assume that? There are plenty of ways to hack into stuff without sql injections.
- elchief 12y ago
  It's the most common vulnerability. https://www.owasp.org/index.php/Top_10_2013-A1-Injection https://www.owasp.org/index.php/Top_10_2013-A1-Injection
  - scrollaway 12y ago
    It's the most common vulnerability on the web. It's certainly not the most common vulnerability in projects built under popular non-php frameworks. Under that model, it's harder to create a situation where a SQL injection is possible than not. Edit: Slack's in PHP, I thought it was in RoR for some reason. Oops.
    - alexhill 12y ago
      Slack is a web service written in PHP, so I'd say elchief's assumption is reasonable.
    - thedufer 12y ago
      Additionally, Slack has had SQLi attacks found against it in the past, which is proof that they aren't defending against it systematically.
- deleted 12y ago
  [deleted]
_trb_ 12y ago
The most important thing to stop sql injection is to validate your parameters on the server side.
- elchief 12y ago
  Yes, but: 1. Not all SQL statements are parameterizable (dynamic identifiers vs literals) 2. Stopping SQL injection doesn't stop Insecure Direct Object References 3. Developers make mistakes 4. Plugins are a risk (example: http://www.zdnet.com/article/over-1-million-wordpress-websites-at-risk-from-sql-injection/ http://www.zdnet.com/article/over-1-million-wordpress-websit...) For parameterization to work you need to be perfect, always. My suggestions are for when someone else fucks up.

by elchief 12y ago

tracker1 12y ago

I think it depends on the structure of the system... If you separate authentication from profile information, then you can run each on separate systems. They were already using bcrypt, which is a fairly strong salted hashing system. As to restricting access, having all access to the database restricted to API servers that provide the limitations you mention, you get a similar level of control, without the complexity of managing per-user database logins. With per-user database logins, you are then subject to whatever system the dbms uses. If you are using systems with looser less fine grained controls, you can be even more limited.

azinman2 12y ago

Why would you assume that? There are plenty of ways to hack into stuff without sql injections.

elchief 12y ago
It's the most common vulnerability. https://www.owasp.org/index.php/Top_10_2013-A1-Injection https://www.owasp.org/index.php/Top_10_2013-A1-Injection
- scrollaway 12y ago
  It's the most common vulnerability on the web. It's certainly not the most common vulnerability in projects built under popular non-php frameworks. Under that model, it's harder to create a situation where a SQL injection is possible than not. Edit: Slack's in PHP, I thought it was in RoR for some reason. Oops.
  - alexhill 12y ago
    Slack is a web service written in PHP, so I'd say elchief's assumption is reasonable.
  - thedufer 12y ago
    Additionally, Slack has had SQLi attacks found against it in the past, which is proof that they aren't defending against it systematically.
deleted 12y ago
[deleted]

_trb_ 12y ago

The most important thing to stop sql injection is to validate your parameters on the server side.

elchief 12y ago
Yes, but: 1. Not all SQL statements are parameterizable (dynamic identifiers vs literals) 2. Stopping SQL injection doesn't stop Insecure Direct Object References 3. Developers make mistakes 4. Plugins are a risk (example: http://www.zdnet.com/article/over-1-million-wordpress-websites-at-risk-from-sql-injection/ http://www.zdnet.com/article/over-1-million-wordpress-websit...) For parameterization to work you need to be perfect, always. My suggestions are for when someone else fucks up.