Evidence that SharePoint has no SQL injection vulnerabilities?

Question

My company has a requirement that all production sites pass an AppScan security scan. Sometimes, when we scan a SharePoint installation, the software detects a blind SQL injection vulnerability. I'm pretty sure this is a false positive--AppScan is probably interpreting some other activity in the HTTP response as success of the blind injection. But it's difficult to prove that this is the case.

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 to this effect, and furthermore, whether any of the stored procedures use dynamically-generated SQL? If everything were sprocs, and none of them dynamic, we would have pretty good evidence that SharePoint has no SQL injection vulnerability.

Answer 1

They aren't all stored procs. In particular, things like cross-lists joins produce some horrendous syntax. For an example, look at the SQL Trace window from this article. Also, since both user controls and API calls can be written by developers, there is no guarantee that you aren't subject to SQL Injection if you are using custom modules.

My guess would be that SharePoint always uses, at the very least, named parameters. However, your best option might to be running a SQL trace and comparing the results. Also, if you are a large enough customer, you might just try calling your local MSFT evangelist (or posting a question on connect.microsoft.com) and seeing if you can get a response.

Answer 2

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 does occasionally use sp_executesql, but this is a parameterized call and is therefore probably safe from injection.