ASP.NET - Доверять уровню = полный?
Вам необходимо удалить параметры предварительного просмотра. Вы можете поставить этот код на успешный обратный вызов, чтобы удалить все параметры предварительного просмотра:
$ ('# outletCode option'). Remove ()
$('#myselect').on('change', function() { var selectedOutlet =this.value; alert(selectedOutlet); $.ajax({ async: true, url : "OutletCode", method : "GET", dataType : "json", contentType: "application/json; charset=utf-8", success: function( json ) { # Remove preview options $('#outletCode option').remove() $.each(json, function(i, value) { $('#outletCode').append($('<option>').text(value).attr('value', value)); }); } }); });
5 ответов
Если они игнорируют политики CAS, это могло бы быть жесткое, продают, чтобы заставить их набирать его назад, так как это делает их задание немного тяжелее (или, по крайней мере, немного менее прощающим). Изменение методов безопасности всегда жестко - как то, когда я должен был убедить своего босса, что использование учетных записей SA в строке подключения SQL наших веб-приложений было плохой идеей - но зависните там.
Полное Доверие позволяет приложению возрастать к управлению любого ресурса на компьютере. В то время как у Вас должен был бы быть дефект безопасности в Вашем приложении для разрешения их, и они будут, вероятно, утверждать, что предотвратили какие-либо эскалации посредством проницательного программирования, напомните им, которые в случае, что что-то происходит, не были бы они скорее, веб-приложение не имело контроля над целым компьютером? Я имею в виду на всякий случай?
Править: Я был немного фанатичен со своим языком здесь. Полное Доверие позволило бы приложению управлять независимо от того, что оно хочет, но только если процесс Пула приложений имеет достаточные права сделать это. Таким образом, если Вы работаете как ограниченный пользователь без прав на сервере кроме того, в чем нуждается applicaition, затем я предполагаю, что нет по существу никакого риска для "Полного Доверия". Действительность - то, что владелец пула приложений, скорее всего, имеет много прав, которые Вы не хотели бы, чтобы Ваше приложение имело (и в некоторых случаях, многие, намного больше), таким образом, намного более безопасно ограничить безопасность приложения и предоставить дополнительные потребности прав индивидуально приложению. Спасибо за исправление, Barry.
Дефекты? Многие. Но самая заслуживающая осуждения вещь является прямой из утилиты CAS:
"... это предоставляет полный доступ к ресурсам Вашего компьютера, таким как доступ к файловой системе или доступ к сети, потенциально работая вне управления системы безопасности".
Это означает, код допустил, что Полное Доверие может выполнить любую другую часть кода (управляемый или иначе) в системе, может позвонить по сети на любую машину, может сделать что-либо в файловой системе (включая изменяющиеся полномочия на ограниченных файлах - даже файлы ОС).
Большинство веб-программистов сказало бы, что "это не проблема, просто мой код", прекрасен...., пока дефект безопасности не неожиданно возникает в их коде, который позволяет взломщику использовать его, чтобы сделать сомнительные вещи. Затем ранее предоставленный Полное Доверие становится довольно неудачным.
Я честно нашел, что sharepoint слишком строг.
Смотрите на следующую страницу для наблюдения то, что может и не может быть сделано на основе доверительных уровней http://msdn.microsoft.com/en-us/library/ms916855.aspx
Одна проблема, с которой я столкнулся сразу, была, я не мог использовать Блок Программы кэширования. Мы использовали этот блок приложений вместо кэширования ASP.NET, потому что мы использовали шаблон MVP и можем открыться, победа формирует приложение.
Другой проблемой не является никакое отражение, это заставило страницу About перестать работать, потому что номер версии вытягивают от метаданных блока.
Я думаю, что лучшее решение не состоит в том, чтобы использовать Sharepoint в качестве хоста приложений. Я только использовал бы Sharepoint в качестве хоста приложений, если бы количество кодирования было столь небольшим, что это не влияло на доверительный уровень, и это будет меньше работы, затем настраивающей новое приложение. Если Вы делаете некоторый тип кодирования, которое начинает врезаться в стены доверительного уровня, перемещать Ваше приложение в надлежащую среду ASP.NET. Но это - просто я, и я смещаюсь. Возможно, необходимо попытаться стремиться к Среднему доверительному компромиссу уровня.
Тодд,
В книге « Программирование Microsoft ASP.Net 3.5 » Дино Эсписито приводятся некоторые веские доводы в пользу запрета полного доверия в приложениях ASP.Net
Среди других причин Дино утверждает, что веб-приложения, открытые в Интернете, являются «одной из самых враждебных сред для компьютерной безопасности, которую вы можете себе представить». И:
публично разоблаченный полностью доверенный приложение является потенциальной платформой для атак хакеров. В чем меньше доверия к приложению, тем более безопасно, что приложение происходит
Я удивлен, что сообщество StackOverflow не описало проблему с полным доверием лучше. Я надеялся на то же самое, поэтому мне не пришлось копаться в куче книг, чтобы найти ответ, ленивая меня.
Я использую полное доверие на своих машинах для разработки .. так что я могу выполнить развертывание в BIN при создании новых код. Я доверяю своему собственному коду и запускаю его в GAC на производстве, потому что создание политик CAS - это боль.
Третья сторона меня бы беспокоила ... однако:
Большинство сторонних решений, найденных в Интернете, также развертываются в GAC (предполагается, по тем же причинам). Это дает им все права независимо от уровня доверия. Похоже, это больше связано с тем, доверяете ли вы третьим сторонам или нет ... и действительно ли вы доверяете своим собственным разработчикам?
Что бы сделал хакер? Сценарий, в котором хакер помещает вредоносную dll в вашу папку BIN, я не считаю очень реалистичным ... независимо от того, сможет ли он это сделать, он также, вероятно, сможет изменить уровень доверия.