难以分析SQLi漏洞后面的查询

Question

我是黑盒笔测试一个同事的网站上常见的漏洞(主要涉及OWASP的前10位)。

在表单字段的值中使用特殊字符返回错误后，我在表单中发现了SQL注入漏洞。该错误指定向某些内部函数提供了不正确的参数数--我怀疑，考虑到表单的用途，它后面有一些特别复杂的查询。

除了这个错误之外，我很难得到任何回应。我尝试了一个浏览器工具来分析这个查询，希望它能够描绘出查询的样子，以便演示如何利用它，但是它根本找不到漏洞。

如何才能更清楚地了解查询的样子？还是说这完全是主观的，是针对这个案子的呢？

我想要找的一个例子是注入SQL的方法，无论它位于何处，都可以依赖于测试漏洞。

注意:如果需要的话，我可以简单地概述一下我已经找到了一个潜在的向量，但是我想解释一下它可能被利用的程度。

Answer 1

在表单字段的值中使用特殊字符返回错误后，我在表单中发现了SQL注入漏洞。

这是一个错误的假设。错误可能表示开发不良的应用程序，该应用程序可能包括SQL注入，也可能不包括SQL注入。说你在这个阶段已经找到了SQLi还为时过早。

此错误指定向某些内部函数提供了不正确的参数数。

我强烈建议搜索错误消息并使用它对应用程序进行指纹识别。如果这是一个原始错误消息，您可以找到产生它的app/web/DB组件。

我尝试了一个浏览器工具来分析这个查询，希望它能够描绘出查询的样子，以便演示如何利用它，但是它根本找不到漏洞。

SQL注入工具现在相当成熟。如果工具没有找到任何东西，那么它很可能不是SQL注入，或者您可能没有正确使用它。产生的有效载荷是否执行您希望它们做的事情(它们是否正确地探测表单)？这个工具显示了什么反应？

OWASP指南是开始研究手动测试方法的一个很好的地方。根据您所观察到的情况，可能需要某种“盲目”的探索，也许您应该仔细研究联合、布尔或基于时间的检测技术。或者，向它抛出平面图或朝圣，如果这是在五极范围内。