Учетные записи безопасности SharePoint - Выполнение пользовательского кода на серверах SharePoint
ОГЛАВЛЕНИЕ
Выполнение пользовательского кода на серверах SharePoint
По умолчанию SharePoint не раскрывает информацию об учетных записях безопасности, для ее обнаружения необходим вредоносный код. Как мы все знаем, уязвимости безопасности могут позволить взломщикам загрузку такого кода, но порой вторжение еще проще.
В простейшем случае злоумышленник может зайти на сервер SharePoint либо локально, либо через службы терминалов и скопировать вредоносный код в папку %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts. Обратите внимание на то, что SharePoint включает эту папку как виртуализованную подпапку в каждый веб-узел SharePoint.
В другом случае SharePoint может ненамеренно ввести вредоносный код, развернув нестандартное решение SharePoint из сомнительного источника, без должного тестирования и проверки кода. Встроенный код ASP.NET в основных страницах и страницах содержимого также является причиной для беспокойства. По умолчанию SharePoint не предоставляет сценарии на стороне сервера, но любой, кто имеет доступ на запись к файлу web.config веб-приложения SharePoint, может изменить правила по обработке сценариев на стороне сервера. Достаточно лишь добавить запись PageParserPath к разделу <PageParserPaths> файла web.config. Каким образом работает запись PageParserPath?
Предположим, что разработчик, использующий SharePoint, звонит коллеге и жалуется на сообщение об ошибке, получаемое при разработке собственной страницы ASP.NET, заявляющей: "Code blocks are not allowed in this file" («Блоки кода не допускаются в этом файле»). Коллега обыскивает Интернет и находит решение в группе новостей или на веб-узле блогов:
<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />
Может быть, он игнорирует предупреждения на тему безопасности, или, возможно, последствия для безопасности даже не упомянуты. Так или иначе, первый разработчик добавляет эту строку к своему файлу web.config, и все счастливы, поскольку он решил проблему.
Увы, он, сам того не зная, открыл дорогу для выполнения любого кода на страницах ASP.NET с полным доверием. Если злоумышленник теперь загрузит вредоносную страницу ASP.NET, то среда SharePoint будет в опасности. Как указано на рис. 3, не имеет значения, где в иерархии коллекции веб-узлов у взломщика есть разрешение на загрузку страницы – это может быть невинный на вид веб-узел небольшой группы. Атака всегда поражает веб-приложение и, возможно, всю ферму серверов, поскольку доступными становятся базы данных и содержимого и конфигурации.
Рис. 3. Включение встроенного кода ASP.NET может нарушить безопасность веб-приложения SharePoint