Evidence that SharePoint does not have SQL injection vulnerabilities?

Question

My company has a requirement that all production sites pass an AppScan security audit. Sometimes, when we scan a SharePoint installation, the software detects a hidden SQL injection vulnerability. I am sure this is a false result. AppScan probably interprets some other actions in the HTTP response as the success of a blind injection. But it is difficult to prove that this is so.

I suspect that SharePoint, both MOSS 07 and WSS 3.0, uses stored procedures exclusively behind the scenes. Does anyone know if there is any documentation from Microsoft on this subject, and in addition, does any of the stored procedures use dynamically generated SQL? If everyone were sprocs, and none of them were dynamic, we would have pretty good evidence that SharePoint does not have a SQL injection vulnerability.

Answer 1

These are not all stored procedures. In particular, things like cross-lists create some kind of horrific syntax. As an example, consider the SQL Trace window from this article . In addition, since both user controls and API calls can be written by developers, there is no guarantee that you are not affected by SQL Injection if you use custom modules.

I assume that SharePoint always uses at least named parameters. However, your best bet might be to use SQL tracing and compare the results. In addition, if you are a big enough client, you can just ask your local MSFT evangelist (or post a question on connect.microsoft.com ) and if you can get an answer.

Answer 2

Thanks. I looked at the profiler myself and found something: It looks like SharePoint only runs stored procedures. There are random bits of pure SQL, but they are apparently limited to "exec sp_oledb_ro_usrname" and "select collationname (...)", which seem to be part of a deep inner thing and may not be executed like SQL in everything, but just go out in the profiler that way ...?

SharePoint sometimes uses sp_executesql, but it is a parameterized call and therefore probably safe from injection.

Answer 3

There are a number of relatively new blind injection injection vectors that are based on delayed response - for example, using WAITFOR DELAY . At least sqlmap and BurpSuite use them (and others, probably, too).

However, these vectors are prone to false positives, because a trigger is a delay in an HTTP response, which can also occur for thousands of other reasons if you are browsing over the Internet. If you have this over the local network, I will be more suspicious, but still investigating other possible causes of the server-side delay. Only if you get a delay sequentially in several independents, you are probably dealing with a vulnerability.

Also note that SharePoint often runs old FrontPage vulnerabilities in many stack scanners, which are also false positives - for details, see this article Extending the SharePoint Server and FrontPage in Security Scan Results .