我的公司要求所有生产站点都通过 AppScan 安全扫描。有时，当我们扫描 SharePoint 安装时，该软件会检测到 SQL 盲注漏洞。我很确定这是一个误报——AppScan 可能将 HTTP 响应中的一些其他活动解释为盲注的成功。但很难证明情况确实如此。
我怀疑 MOSS 07 和 WSS 3.0 的 SharePoint 只在幕后使用存储过程。有谁知道微软是否有任何关于此效果的文档，此外，是否有任何存储过程使用动态生成的 SQL？如果一切都是 sproc，并且它们都不是动态的，那么我们将有很好的证据表明 SharePoint 没有 SQL 注入漏洞。
它们并不都是存储过程。特别是，像交叉列表连接这样的东西会产生一些可怕的语法。例如，查看本文中的 SQL Trace 窗口。此外，由于开发人员可以编写用户控件和 API 调用，因此如果您使用自定义模块，则无法保证您不会受到 SQL 注入的影响。
我的猜测是，SharePoint 至少总是使用命名参数。但是，您最好的选择可能是运行 SQL 跟踪并比较结果。此外，如果您是一个足够大的客户，您可以尝试致电您当地的 MSFT 传播者（或在connect.microsoft.com上发布问题），看看是否能得到答复。
谢谢。我自己查看了分析器，发现了一些东西： 看起来 SharePoint 只是在执行存储过程。偶尔会出现一些纯 SQL，但这些似乎仅限于“exec sp_oledb_ro_usrname”和“select collationname(...)”，它们似乎是一些深入的内部事物，并且可能不会作为 SQL 在所有，但只是以这种方式出现在分析器中......？
SharePoint 偶尔会使用 sp_executesql，但这是一个参数化调用，因此可能不会被注入。
有许多基于响应延迟的相对较新的盲 SQL 注入向量 - 例如使用WAITFOR DELAY. 至少 sqlmap 和 BurpSuite 使用它们（可能还有其他人）。
然而，这些向量很容易出现误报，因为触发因素是 HTTP 响应延迟，如果您通过 Internet 进行扫描，也可能由于其他数千个原因而发生这种情况。如果您通过 LAN 获得这些，我会更加怀疑，但仍会调查服务器端其他可能的延迟原因。仅当您在多次独立尝试中始终如一地获得延迟时，您可能正在处理一个漏洞。
另请注意，SharePoint 经常在许多 vuln 扫描程序中触发旧的 FrontPage 漏洞，这也是误报 - 有关详细信息，请参阅本文“安全扫描程序结果中的 SharePoint 和 FrontPage 服务器扩展”。