Доказательства того, что SharePoint не имеет уязвимостей SQL-инъекций?

Question

У моей компании есть требование, чтобы все производственные площадки проходили проверку безопасности AppScan. Иногда, когда мы сканируем установку SharePoint, программное обеспечение обнаруживает скрытую уязвимость SQL-инъекции. Я уверен, что это ложный результат. AppScan, вероятно, интерпретирует некоторые другие действия в ответе HTTP как успех слепой инъекции. Но трудно доказать, что это так.

Я подозреваю, что SharePoint, как MOSS 07, так и WSS 3.0, использует хранимые процедуры исключительно за кулисами. Кто-нибудь знает, есть ли какая-либо документация от Microsoft на этот счет, и, кроме того, использует ли какая-либо из хранимых процедур динамически генерируемый SQL? Если бы все были sprocs, и ни один из них не был динамичным, у нас было бы довольно хорошее доказательство того, что SharePoint не обладает уязвимостью SQL-инъекции.

Answer 1

Они не все хранятся в процедурах. В частности, такие вещи, как перекрестные списки, создают какой-то ужасающий синтаксис. Например, посмотрите окно SQL Trace от this article. Кроме того, поскольку как пользовательские элементы управления, так и вызовы API могут быть написаны разработчиками, нет гарантии, что вы не подвержены SQL Injection, если используете пользовательские модули.

Мое предположение заключается в том, что SharePoint всегда использует, по крайней мере, именованные параметры. Однако ваш лучший вариант может заключаться в использовании трассировки SQL и сравнении результатов. Кроме того, если вы достаточно большой клиент, вы можете просто попросить своего местного евангелиста MSFT (или опубликовать вопрос на connect.microsoft.com) и посмотреть, сможете ли вы получить ответ.

Answer 2

Спасибо. Я сам посмотрел на профилировщик и нашел некоторые вещи: Похоже, что SharePoint выполняет только хранимые процедуры. Существуют случайные биты чистого SQL, но они, по-видимому, ограничены «exec sp_oledb_ro_usrname» и «select collationname (...)», которые, как представляется, являются частью глубокой внутренней вещи и, возможно, не выполняются как SQL в все, но просто выходят в профилировщике таким образом ...?

SharePoint иногда использует sp_executesql, но это параметризованный вызов и поэтому, вероятно, безопасен от инъекции.

Answer 3

Существует ряд относительно новых слепых векторов инъекций SQL, которые основаны на задержке ответа - например, с использованием WAITFOR DELAY. По крайней мере sqlmap и BurpSuite используют их (и другие, вероятно, тоже).

Эти векторы, однако, склонны к ложным срабатываниям, поскольку триггер - это задержка HTTP-ответа, которая может случиться и по тысячам других причин, если вы сканируете через Интернет. Если у вас есть это по локальной сети, я буду более подозрительным, но все еще исследую другие возможные причины задержки на стороне сервера. Только если вы получаете задержку последовательно в нескольких независимых, вы, вероятно, имеете дело с уязвимостью.

Также обратите внимание, что SharePoint часто запускает старые уязвимости FrontPage во многих стековых сканерах, которые также являются ложными срабатываниями - подробности см. В этой статье "SharePoint and FrontPage Server Extensions in security scanner results".