Of the public disclosures I've seen from recently compromised sites, it seems common for only the database to be leaked, rather than the application code, or rather than a complete takeover. Is this because there is a class of common attacks that are limited to read-only database access?
The first few that come to mind are:
- An SQL injection attack where the database user in question has only the SELECT privilege.
- A compromise of the primary database backups or the offsite database backups. While these aren't read only, there's little likelihood of escalating the compromise by writing to backups.
- A compromise of a shell account on a database server. Even though you could use root privileges on a database box to gain a user account in the database itself, this would probably be a noisy action that would get the compromise noticed. You could still copy the entire database contents without being noticed.
It's also entirely possible that the attackers in the leaks you are talking about had full privileges or at least more privileges than just read-only but chose not to use them. Or they did use them but that use hasn't been detected yet. Or that they have the full application code but chose not to leak that.
An interesting thought I just had while writing this about preventing 1. by reducing the attack surface is to have a separate database user account that only has access to the credentials table and your normal, read-only user doesn't have access to this table. That way, only an SQL injection in the login form can compromise your password hashes. Any SQL injection in another part of the web application cannot see the password hashes (or whatever other sensitive data you have).
Database is the gold mine that is why leaking the data in it means all the bad things. Application source code is important in some cases but if you look at the architecture of modern applications, most of the data comes from the back end database. Credentials, PIIs, credit card numbers, financial and business data, almost everything you want to protect is in the database.
Compromising the server (like getting the shell) only matters in case of bot attacks so that the bot network is expanded. Targeted attacks are always for the data. Therefore, compromising the database means achieving the objective.
As regards your "command attacks" thing, majority of the websites are compromised through SQL injection which directly executes attacker queries on the database. Read only database is the minimum you get in SQL injection. SQLi can result in full compromise of the machine as well by uploading shell code through the "INTO DUMPFILE" directive and these calling the shell through the web application resulting in a complete interactive shell through browser.
So data leakage most of the time achieve the objective that is why attackers stop there. If not, SQL injection provides many other attack avenues as well.
I guess if they find a SQL injection and the user that the website uses to query the database only has read access, then the result would indeed be that he can only do a read-only sql injection attack. But I do not think there is a specific class for that type of attacks. In general we just prepend read-only name of attack
If the database is the only compromised part of the web application, it's almost everytime a SQL Injection, which abuses an application function (e.g. a search form) in order to extract arbitrary data from the underlying database.
A database leak could also be caused by an internal attack, performed by an employee who had enough privileges to access the database.
Partial and complete database dumps can also be found via Google Hacking, which uses search engines to discover sensitive files that got indexed.
Lastly, I'd include application errors that might disclose data from the database if exceptions are not handled correctly.