每个人都知道或应该知道参数化查询有助于防止 SQL 注入(inject)。我看到的所有教程和文档都围绕着使用准备好的 SQL 查询来处理表单输入。但是当没有任何表单输入时呢？ IE。用户登录后的后续查询，例如 $stmt = "SELECT theme_preference FROM users WHERE user_id = '1234'";
$query = mysqli_query($conn, $stmt);
攻击者是否可以通过任何方式利用此漏洞？ (假设我正在使用 PHP)。
最佳答案
问题不在于SQL查询中写入的数据来源是否为http形式。即使它来自当前请求也不是。
问题是您是否信任数据源。这可能是一个复杂的问题。
您显然不信任来自当前请求的内容。您也不相信可能来自较早请求的某些内容，例如数据库中被请求数据修改的示例字段。但是您也可能信任也可能不信任数据库中的其他 字段。例如，您有 IT 操作人员或数据库管理员。你相信他们不会在数据库字段中注入(inject)某种 XSS 或二次 SQLi 攻击来窃取用户信用卡数据，这些数据存储在经过审计的表中，这样他们就不会在不被发现的情况下直接进入并转储它吗？如果他们在未经审计的表中的正确位置注入(inject) javascript 或聪明的 SQLi，他们可能会通过利用易受攻击的应用程序窃取信用卡信息，然后将其改回并删除所有痕迹。
此外，一个应用程序可能有不同的数据源，例如，其他系统可能会在 API 上上传文件(比如 XML)，来自这些系统的数据将被处理，其中一些最终会进入 UI 或用于 SQL 查询。如果您信任这些来源，您可以选择不实现针对 SQLi 或 XSS 的保护。但是，当它很容易时，你为什么要这么做？多层防御总比如履薄冰。
所以简而言之，问题是信任。如果您绝对信任数据源(例如，因为它是静态的、硬编码的或出于其他原因)，那么直接在查询中使用它是可以的。但是在 SQL 注入(inject)的情况下，正确使用它(即在参数中)非常容易，您应该这样做。
还要考虑 future 的变化。您在不带参数的 SQL 字符串中编写它，因为您知道它现在是安全的。几个月过去了，有人添加了一项新功能，修改了您的查询，添加了更多参数，其中一个来自请求。但模式已经存在，他可能只是复制粘贴并使用模式 - 而您的应用程序很容易受到攻击。
我的最后一点是静态安全扫描器，它们会查看您的源代码。如果变量包含在查询字符串本身中而不使用参数，几乎所有这些都会为 SQLi 标记您的代码。这当然可能是误报，但我怀疑你是否愿意为这些发现而烦恼，因为你首先可以避免它们。
所以有时候不仅仅是技术可利用性，还有其他方面。
关于php - 在不处理用户输入时使用未经准备的 SQL 查询的潜在危险？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40696658/