我的公司有一个要求，所有生产站点都必须通过AppScan安全扫描。有时，当我们扫描SharePoint安装时，该软件会检测到盲SQL注入漏洞。我相当肯定这是虚假警报--AppScan可能将HTTP响应中的其他活动解释为盲注入的成功。但很难证明这是情况。
我怀疑SharePoint（包括MOSS 07和WSS 3.0）在后台完全使用存储过程。是否有任何来自Microsoft的相关文档？此外，是否有任何存储过程使用动态生成的SQL？如果所有东西都是存储过程，而且没有一个是动态的，那么我们就有很好的证据表明SharePoint没有SQL注入漏洞。
它们并不都是存储过程。特别是一些诸如交叉列表连接之类的东西会产生一些可怕的语法。例如，请查看这篇文章中的 SQL Trace 窗口。此外，由于开发人员可以编写用户控件和 API 调用，因此无法保证在使用自定义模块时不会受到 SQL 注入的影响。
我的猜测是SharePoint始终使用至少命名参数。然而，你最好的选择可能是运行一个SQL跟踪并比较结果。此外，如果你是一个足够大的客户，你可以尝试联系本地的MSFT布道者（或在connect.microsoft.com上发布一个问题），看看是否能得到回应。
Thanks. I looked at the profiler myself and found some things: It looks like SharePoint is only executing stored procedures. There are occasional bits of pure SQL, but these seem to be limited to "exec sp_oledb_ro_usrname" and "select collationname(...)", which appear to be some deep-down internal thing, and possibly are not being executed as SQL at all, but are just coming out in the profiler that way...?
SharePoint有时会使用sp_executesql，但这是一个参数化调用，因此很可能不会受到注入的影响。
There s a number of relatively new blind SQL injection vectors which are based on response delay - for example using WAITFOR DELAY. At least sqlmap and BurpSuite use them (and others probably too).
These vectors however are prone to false positives, because the trigger is, well, HTTP response delay, which may also happen for thousand other reasons if you re scanning over Internet. If you got these over LAN, I would be more suspicious but still investigate other possible delay causes on the server side. Only if you get the delay consistently in a number of independent tried, you are probably dealing with a vulnerability.
Also note that SharePoint often triggers old FrontPage vulnerabilities in many vuln scanners, which are also false positives - for details see this article "SharePoint and FrontPage Server Extensions in security scanner results".
