最先想到的几个是：

1. SQL 注入攻击，其中有问题的数据库用户只有 SELECT 权限。
2. 主数据库备份或异地数据库备份的妥协。虽然这些不是只读的，但通过写入备份来升级危害的可能性很小。
3. 数据库服务器上的 shell 帐户的危害。即使您可以在数据库机器上使用 root 权限来获得数据库本身的用户帐户，这也可能是一个嘈杂的操作，会引起妥协的注意。您仍然可以在不被注意的情况下复制整个数据库内容。

您所谈论的泄漏中的攻击者也完全有可能拥有完全权限或至少比只读权限更多的权限，但选择不使用它们。或者他们确实使用了它们，但尚未检测到这种用途。或者他们拥有完整的应用程序代码，但选择不泄露。

我在写这篇文章时想到了一个关于防止 1. 通过减少攻击面的有趣想法是拥有一个单独的数据库用户帐户，该帐户只能访问凭据表，而您的普通只读用户无权访问此表. 这样，只有登录表单中的 SQL 注入才能破坏您的密码哈希值。Web 应用程序另一部分中的任何 SQL 注入都无法看到密码哈希（或您拥有的任何其他敏感数据）。

数据库是金矿，这就是为什么泄露其中的数据意味着所有坏事。应用程序源代码在某些情况下很重要，但如果您查看现代应用程序的架构，大部分数据都来自后端数据库。凭证、PII、信用卡号、财务和业务数据，几乎所有您想要保护的内容都在数据库中。

破坏服务器（例如获取外壳）仅在机器人攻击的情况下才重要，以便扩展机器人网络。有针对性的攻击总是针对数据。因此，破坏数据库意味着实现目标。

至于您的“命令攻击”，大多数网站都通过 SQL 注入入侵，直接在数据库上执行攻击者查询。只读数据库是您在 SQL 注入中获得的最低要求。SQLi 也可以通过“INTO DUMPFILE”指令上传 shell 代码并通过 Web 应用程序调用 shell，从而通过浏览器生成一个完整的交互式 shell，从而导致机器完全受到攻击。

因此，数据泄漏大多数时候都达到了攻击者止步于此的目标。如果没有，SQL 注入也提供了许多其他攻击途径。

我猜如果他们发现了SQL注入并且网站用来查询数据库的用户只有读取权限，那么结果确实是他只能进行只读sql注入攻击。但我认为这种类型的攻击没有特定的类别。一般来说，我们只是在前面加上只读的攻击名称

如果数据库是 Web 应用程序中唯一受到威胁的部分，那么几乎每次都是SQL 注入，它滥用应用程序功能（例如搜索表单）以从底层数据库中提取任意数据。

数据库泄漏也可能是由内部攻击引起的，由具有足够权限访问数据库的员工执行。

部分和完整的数据库转储也可以通过Google Hacking找到，它使用搜索引擎来发现被索引的敏感文件。

最后，我将包含应用程序错误，如果异常处理不正确，这些错误可能会泄露数据库中的数据。