ASP.NET — уровень доверия = полный?

Тодд,

Книга "Programming Microsoft ASP.Net 3.5", автор Дино Эспизито, содержит веские аргументы в пользу запрета полного доверия в приложениях ASP.Net.

Среди других причин Дино заявляет, что веб-приложения, открытые для доступа в Интернет, являются «одной из самых неблагоприятных сред для компьютерной безопасности, которую вы только можете себе представить». А также:

общедоступное полностью доверенное приложение является потенциальной платформой для атак хакеров. Чем меньше доверия приложению, тем более безопасным оно оказывается.

Я удивлен, что сообщество StackOverflow не описало проблему с полным доверием лучше. Я надеялся на то же самое, поэтому мне не пришлось копаться в куче книг, чтобы найти ответ, ленивый я.

Если они игнорируют политику CAS, может быть трудно убедить их отказаться от нее, поскольку это немного усложняет их работу (или, по крайней мере, делает их менее снисходительными). Менять методы обеспечения безопасности всегда сложно — например, когда мне пришлось убеждать своего босса, что использование учетных записей SA в строке подключения SQL наших веб-приложений — плохая идея, — но держитесь.

Полное доверие позволяет приложению получить контроль над любым ресурсом на компьютере. Хотя у вас должен быть недостаток безопасности в вашем приложении, чтобы разрешить это, и они, вероятно, будут утверждать, что предотвратили любую эскалацию с помощью проницательного программирования, напомните им, что в случае, если что-то произойдет, не лучше ли им веб-приложение не контролировало весь компьютер? В смысле, на всякий случай?

РЕДАКТИРОВАТЬ: я немного переусердствовал со своим языком здесь. Полное доверие позволит приложению контролировать все, что оно хочет, но только если у процесса пула приложений есть достаточные права для этого. Поэтому, если вы работаете как пользователь с ограниченными правами без каких-либо прав на сервере, кроме тех, которые нужны приложению, то я полагаю, что для «Полного доверия» практически нет риска. Реальность такова, что владелец пула приложений, скорее всего, имеет ряд прав, которые вы не хотели бы, чтобы ваше приложение имело (а в некоторых случаях, многие, многие другие), поэтому гораздо безопаснее ограничить безопасность приложения и предоставить дополнительные права индивидуально. к приложению. Спасибо за поправку, Барри.

Недостатки? Много. Но самое ужасное прямо из утилиты CAS:

«... он обеспечивает полный доступ к ресурсам вашего компьютера, таким как файловая система или доступ к сети, потенциально работающим вне контроля системы безопасности».

Это означает, что код с полным доверием может выполнять любую другую часть кода (управляемую или иную) в системе, может обращаться по сети к любому компьютеру, может делать что угодно в файловой системе (включая изменение прав доступа к файлам с ограниченным доступом — даже к файлам ОС). ).

Большинство веб-программистов сказали бы: «Это не проблема, это просто мой код», и это нормально… пока в их коде не обнаруживается брешь в системе безопасности, позволяющая злоумышленнику использовать его для сомнительных целей. Тогда ранее предоставленное полное доверие становится весьма неудачным.

Честно говоря, я обнаружил, что Sharepoint слишком ограничителен.

Взгляните на следующую страницу, чтобы узнать, что можно и что нельзя делать на основе уровней доверия http://msdn.microsoft.com/en-us/library/ms916855.aspx

Одна проблема, с которой я сразу столкнулся, заключалась в том, что я не мог использовать блок приложений кэширования. Мы использовали этот блок приложения вместо кэширования ASP.NET, потому что использовали шаблон MVP и могли открыть приложение winforms.

Другая проблема — отсутствие отражения, это привело к сбою страницы «О программе», поскольку номер версии вытаскивается из метаданных сборки.

Я думаю, что лучшее решение — не использовать Sharepoint в качестве хоста приложений. Я бы использовал Sharepoint в качестве хоста приложений только в том случае, если объем кода был настолько мал, что не влиял на уровень доверия, и это было бы меньше работы, чем настройка нового приложения. Если вы выполняете какой-то тип кодирования, который начинает упираться в стены уровня доверия, переместите свое приложение в подходящую среду ASP.NET. Но это только я, и я предвзят. Возможно, вам следует попытаться достичь среднего уровня доверия.

Я использую полное доверие на своих машинах для разработки, поэтому я могу развертывать в BIN при создании нового кода. Я доверяю своему собственному коду и запускаю его в GAC на производстве, потому что создание политик CAS — это проблема.

Сторонняя вещь заставила бы меня побеспокоиться.. однако:

Большинство сторонних решений, найденных в Интернете, также развертываются в GAC (при условии, что по тем же причинам). Это дает им все права независимо от уровня доверия. Похоже, это больше связано с тем, доверяете ли вы третьим сторонам или нет ... и действительно ли вы доверяете своим собственным разработчикам?

Что бы сделал хакер? Сценарий, когда хакер сбрасывает вредоносную dll в вашу папку BIN, я не считаю очень реалистичным. Независимо от того, может ли он это сделать, он также, вероятно, может изменить уровень доверия.