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

Question

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

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

Answer 1

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

Я думаю, что 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 во многих сканерах vuln, которые также являются ложными срабатываниями - подробности см. В этой статье "Расширения SharePoint и FrontPage Server в результатах сканирования безопасности" .