Why would you assume that? There are plenty of ways to hack into stuff without sql injections.
It's the most common vulnerability. https://www.owasp.org/index.php/Top_10_2013-A1-Injection
Re:Slack was hacked
by scrollaway on Friday March 27, 2015 @01:47PM
(#9277876)
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.
Slack is a web service written in PHP, so I'd say elchief's assumption is reasonable.
Additionally, Slack has had SQLi attacks found against it in the past, which is proof that they aren't defending against it systematically.
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.
The most important thing to stop sql injection is to validate your parameters on the server side.
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-websit...)
For parameterization to work you need to be perfect, always. My suggestions are for when someone else fucks up.
* Use 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 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-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]