有没有SQL注入漏洞的证据？

Question

我的公司要求所有生产站点都通过AppScan安全扫描。有时，当我们扫描SharePoint安装时，该软件会检测到盲目的SQL注入漏洞。我很确定这是误报 - AppScan可能会将HTTP响应中的其他一些活动解释为盲注射的成功。但很难证明情况就是这样。

我怀疑SharePoint（MOSS 07和WSS 3.0）仅在幕后使用存储过程。有没有人知道微软是否有这方面的文件，此外，是否有任何存储过程使用动态生成的SQL？如果一切都是sprocs，而且没有一个是动态的，我们就会有很好的证据表明SharePoint没有SQL注入漏洞。

Answer 1

它们不是所有存储过程。特别是，交叉列表连接之类的东西会产生一些可怕的语法。有关示例，请查看this article中的SQL Trace窗口。此外，由于开发人员可以编写用户控件和API调用，因此如果您使用自定义模块，则无法保证您不受SQL注入。

我的猜测是SharePoint总是至少使用命名参数。但是，您最好的选择可能是运行SQL跟踪并比较结果。此外，如果您是一个足够大的客户，您可以尝试致电当地的MSFT福音传道者（或在connect.microsoft.com上发布问题），看看您是否能得到回复。

Answer 2

感谢。我自己看了一下剖析器，发现了一些东西： 看起来SharePoint只是执行存储过程。偶尔会有一些纯SQL，但这些似乎仅限于“exec sp_oledb_ro_usrname”和“select collat​​ionname（...）”，它们似乎是一些内部深层次的东西，并且可能没有像SQL一样被执行所有，但只是以这种方式出现在探查器中......？

SharePoint偶尔会使用sp_executesql，但这是一个参数化调用，因此可能无法注入。

Answer 3

有许多基于响应延迟的相对较新的盲SQL注入向量 - 例如使用WAITFOR DELAY。至少sqlmap和BurpSuite使用它们（其他可能也是如此）。

然而，这些向量容易出现误报，因为触发器是HTTP响应延迟，如果您通过Internet扫描，这也可能由于其他数千个原因而发生。如果你通过局域网获得这些，我会更加怀疑，但仍然调查服务器端的其他可能的延迟原因。只有当你在一些独立尝试中得到延迟时，你可能正在处理一个漏洞。

另请注意，SharePoint经常在许多漏洞扫描程序中触发旧的FrontPage漏洞，这也是误报 - 有关详细信息，请参阅本文"SharePoint and FrontPage Server Extensions in security scanner results"。