除了 Philipp 所说的，请记住，SQL 注入攻击通常是在不知道数据库结构的情况下进行的，但是一旦暴露了漏洞，就可以使用它来确定结构。

例如，曾经教过的第一个 SQL 注入字符串曾经是 ';shutdown--

这假设用户提供的数据在 SQL 查询中被放在引号中，因此字符串中的第一个引号将其关闭，后面的分号结束语句，这可能会导致错误。但是，仍会执行以下语句，即shutdown. --表示其余为注释。因此，如果输入未经过清理，此字符串可能会立即关闭服务器。

在许多数据库系统（例如 SQL 服务器）中向前迈出相同的一步，系统表列表是众所周知的，如果执行查询的帐户具有权限，它可以用于列出用户、表、存储过程、视图和其他 SQL 配置。一旦列出，它们就可以被删除、导出，并且表或视图的结构也可以被列出。

类似地，可以构造查询以绕过身份验证，例如通过字符串，例如 ' or '1'='1' --

像上面这样的字符串将被插入到一个WHERE子句中，无论提供什么用户名或密码，这都会导致一个真实的评估，允许用户在不提供任何凭据的情况下进行身份验证。例如：

SELECT * FROM USERS WHERE UserName = '' or '1'='1' --

简而言之，一旦 SQL 注入攻击成功，攻击者就有能力在您的服务器上运行代码，就威胁建模而言，这应该被视为就好像他们坐在服务器本身上一样。

为了避免攻击，大多数框架和数据库系统都提供了参数化查询的机制。尽管您应该检查您的平台，但参数化查询通常是最安全的方式。如果您必须自己构建 SQL 查询（例如传递给需要它的某些外部 API），那么请考虑对其进行正确编码，尽管我会尽量避免它。

那要看。

1. 在某些 Web 应用程序中，语法错误的 SQL 语句会导致错误消息被转发到访问者看到的 HTML 输出中。这可能会给攻击者一些关于查询外观的信息。（“您在‘myapp_tbl_users’附近的 SQL 查询中有错误。”）。为避免这种情况，请将您的网络服务器配置为不输出详细的错误消息。
2. 在某些情况下，SQL 注入攻击会导致将数据库内容打印到前端。当他们发现这样的攻击时，他们还可以使用它来输出有关数据库的元信息，例如其中存在哪些表。
3. 永远不要假设所有的攻击者都是外部的。一个安全的系统还应该能够抵御知道应用程序如何工作的内部攻击者。
4. 您的 Web 应用程序中可能存在一个不相关的漏洞，该漏洞会泄露源代码。这些通常不是那么重要，但是当您的应用程序中还存在 SQL 注入时，它可以帮助攻击者获取有关数据库结构的信息。
5. 攻击者只能猜测。猜测可以是自动化的（运行一个暴力破解可能的表名的脚本）。

但是避免任何这些问题的最佳方法是首先避免 SQL 注入。与连接字符串相比，与 SQL 数据库通信有很多更好的方法。使用存储过程、准备好的语句或 ORM 包装器。

是的 - 他们可以使用INFORMATION_SCHEMA找出您的数据库的结构。

许多在线教程，比如这个教程，会告诉你整个过程，从一个简单的漏洞利用到提取所有数据。

从防御者的角度来看，您可以拒绝访问 INFORMATION_SCHEMA 表 - 我怀疑您的合法应用程序曾经使用过它们。然而，在这种情况下，攻击者可以暴力破解表和列名，正如 Philipp 所建议的那样。我实际上从未见过拒绝访问的 Web 应用程序 - 最好首先花精力防止 SQL 注入。