CODEWITHSUNDEEP
sharepointapiarchitecturesql-injection
xmt11
xmt11

Reputation:

Evidence that SharePoint has no SQL injection vulnerabilities?

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.

Upvotes: 7

Views: 3917

Answers (3)

kravietz
kravietz

Reputation: 11285

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".

Upvotes: -1

xmt11
xmt11

Reputation:

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.

Upvotes: 1

Cory Foy
Cory Foy

Reputation: 7222

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.

Upvotes: 2

Related Questions