SQL 注入 是否存在易受攻击的 url 不包含“等于”(=) 符号的情况

信息安全 Web应用程序 sql注入 注射
2021-08-13 18:35:07

我有一个问题希望你能帮忙？

我正在寻找从我的网站过滤/grep 一个很长的蜘蛛网址列表，以仅获取可能容易受到 sql 注入攻击的网址。

我的问题： 说任何可能容易受到 sql 注入攻击的 url 是否总是在 url 中包含一个“等于”(=) 符号？

因此，如果我要对所有在 url 中包含“=”符号的 url 进行 grep，我是否会错过任何其他不包含“=”符号但仍可能易受攻击的 url？

例如，这些都包含一个“=”符号，并且可能容易受到 sql 注入的攻击。

http://[website]/index.php?itemid=10
http://www.[yoursite].org/site/page.asp?CID=72&DID=
http://www.[mysite].com/site/page.asp?=

是否存在 url 不包含 '=' 并且仍然容易受到 sql 注入攻击的情况？

- - - -编辑 - - - -

我只对更改/注入浏览器 URL 栏中的 URL 感兴趣，以查看我列表中的任何 URL 是否可能容易受到 sql 注入的攻击（即对注入表单或 POST 请求等不感兴趣）。

我有一个 txt 文件中的 URL 列表

文件.txt

http://www.[site].com/index.php?itemid=10
http://www.[site].com/
http://www.[site].com/site/page.asp?CID=72&DID=
http://www.[site].com/animals/pictures
http://www.[site].com/pictures
http://www.[site].com/index.php?itemid=7
http://www.[site].com/faq

我想过滤/grep这个txt文件，所以我只得到包含'='符号的URL，如下所示：

过滤文件.txt

http://www.[site].com/index.php?itemid=10
http://www.[site].com/site/page.asp?CID=72&DID=
http://www.[site].com/index.php?itemid=7
http://www.[site].com/site/page.asp?CID=72&DID=

在 FILTEREDFILE.txt 中使用这些 URL，然后我将使用一个foreach循环在每个 URL 的末尾添加一个撇号，通过查看响应内容长度来查看它是否容易受到 sql 注入，以查看是否存在更改/差异。

我知道即使在 URLS 上并且不包含“=”，表单和 POST 请求等中仍然可能存在 sql 注入漏洞，但我目前对这些不感兴趣。

重要的：

我只对可以通过更改/更改 URL 本身来确定的漏洞感兴趣（即通过在 http://www.[site].com/index.php?itemid=7 的末尾添加撇号等） .

我想知道的是，是否通过对包含“=”符号的 URL 的 txt 文件进行 greping 操作，我是否会错过任何可能仍然易受攻击但不包含“=”符号的 URL。（不包括表单、POSTS、url 重写，只是在 URL 栏中操作 URL）

希望这能更好地解释我的问题，

感谢您的帮助

4个回答

SQL 注入可以在请求的任何部分执行。HTTP 请求的任何参数都可以包含可以欺骗应用程序将其注入数据库的 SQL 数据。

例如，亚马逊在 URL http://www.amazon.com/gp/product/B008GFRB9E中有产品 ID这称为 URL 重写，网络服务器从 URL 中提取产品 ID 并使用它来查询数据库它。

如果没有可用的源代码，就无法知道正在执行哪些 SQL 查询。一个 Web 应用程序可以对连接的 IP 地址执行反向 DNS，并将该名称插入数据库中。但是 IP 可以解析为执行 SQL 注入的字符串。

以下是从 URL 获取变量到 Web 应用程序的一些方法：

解析链接时，请记住字符可以进行 URL 编码。

即使没有 URL 重写，也可以不包含等号，但这取决于网站编码的糟糕程度。

如果未正确清理，将导致 sql 查询的 web url 的任何部分都可用于执行 sql 注入。

获取变量可以不带值传递，只传递定义。

考虑这个例子：

网址： http://site.com/user.php?user-1234

代码：

foreach ($_GET as $k => $v) {
    $k2 = explode('-', $k);
    if ($k2[0]='user') $res=$k2[1];
}
//do sql query with $res

所有输入都容易受到 SQL 注入的攻击，因此您需要始终在服务器端进行过滤和检查。不要担心它来自哪里，只要您使用来自用户的变量，读取文件，或多或少没有硬编码的值，您应该进行适当的转义和检查。

如果您还不熟悉 OWASP，我建议您从他们的 SQL 注入指南开始。

我不会依赖相等的字符串作为检测器，你可能会得到一个改变功能的 SQL 注入，或者通过简单的注释注入攻击来触发布尔检查。

此外，如其他答案中所述，如果您过滤查询字符串，则会错过处理通过POST方法传输的表单数据的页面。例如，如果您有处理表单提交结果的 url，它可能没有任何 get 参数，但在POST处理值时仍然可能存在 SQL 注入。我确实阅读了您的完整帖子，但我不确定如果您正在努力测试您的应用程序，为什么您不想检查所有输入表单。如果您有资金，最好运行一些自动化工具，例如 nikto、burp 的扫描仪或 AppScan。

看起来你付出了很大的努力来只解决部分问题。另外，如果您有源代码，如果您是程序员，我会从那里开始，而不是识别页面，因为可能有多个页面调用相同的函数。

简短的回答不，您不能假设只有带有 = 的 URL 才是 SQL 注入的可能向量。

这个假设的问题在于它忽略了使用内容处理程序和 Web 框架，它们使用 url 路径信息来确定调用什么处理程序/过程以及如何处理路径信息。考虑许多使用这种方法的基于 REST 的服务以及许多流行的 Web 框架。

我可以有一个像

http://example.com/handler/argument1/argument2/arguement3

其中处理程序被调用并传递了argument1、argument2和argument3。根据处理程序的实现方式和作用，它很容易为 sql 注入提供一个向量。

其它你可能感兴趣的问题
上一篇测试防火墙规则 (Linux) 下一篇两因素身份验证：什么时候值得？