SQL注入可能是可能的

Question

我正在使用 ZAP 软件生成 PEN 测试报告。它说 SQL 注入可能是可能的：

文件网址：

/themes/oceanwpchild/uiwidgets.css?ver=1677756637

和

/themes/oceanwpchild/uiwidgets.js?ver=1677756637

方法：获取

Attack : case randomblob(100000) when not null then 1 else 1 end

证据：

查询时间可使用参数值控制 [case randomblob(100000) when not null then 1 else 1 end ]，导致请求耗时[287]毫秒，参数 值 [case randomblob(100000) when not null then 1 else 1 end ]，这导致了 请求花费 [287] 毫秒，当原始未修改的查询具有值时 [1677756637] 用了 [151] 毫秒。

我想知道 SQL 注入是如何实现的。如果 SQL 注入是可能的，那么我们如何防止它，因为查询中可能存在 SQL 注入，这些是 CSS 和 JS 文件。

Answer 1

ZAP 报告表明两个资源的 URL 中可能存在潜在的 SQL 注入漏洞：/themes/oceanwpchild/uiwidgets.css 和 /themes/oceanwpchild/uiwidgets.js。

需要注意的是，CSS 和 JS 文件本身不能通过 SQL 注入攻击进行利用，因为它们不与数据库交互。然而，该漏洞可能存在于生成这些文件的代码中，例如根据用户输入动态生成 CSS 或 JS 文件的服务器端脚本或 Web 应用程序框架。

要了解在这种情况下如何发生 SQL 注入，了解 Web 应用程序如何处理用户输入很重要。当用户通过表单或 URL 参数提交数据时，应用程序可以使用该数据来构建 SQL 查询以与数据库交互。如果应用程序没有正确清理或验证用户输入，攻击者可能能够操纵 SQL 查询并注入他们自己的命令。

在这种情况下，ZAP 报告表明攻击者可以通过将值“case randomblob(100000) when not null then 1 else 1 end”注入 URL 参数“ver”来操纵查询时间。通过注入这个值，攻击者可能会操纵 SQL 查询并在数据库上执行任意命令，具体取决于查询的构造方式。

为防止 SQL 注入漏洞，正确清理和验证用于构造 SQL 查询的所有用户输入非常重要。这可以通过使用参数化查询、输入验证和其他安全最佳实践来完成。此外，定期将软件和 Web 应用程序框架更新到最新版本有助于缓解已知漏洞。