“Безопасность доступа к коду” какого-либо использования реального мира?
Никакой программист не является островом. Кто-то оказывается перед необходимостью читать их код один день. Это было повторено здесь много раз прежде:
Всегда код, как будто парень, который заканчивает тем, что поддержал Ваш код, будет жестоким психопатом, который знает, где Вы живете. - Martin Golding (возможно)
Однако если их стиль соответствует, существуют другие намного более важные вещи оценить при найме программиста. Но если они крайне отказываются использовать комментарии или пытаться сделать их код читаемым другим, это - недопустимое.
8 ответов
Я довольно часто сталкиваюсь с безопасностью доступа к коду в «реальном мире», часто тогда, когда я меньше всего этого ожидаю. И в каком-то смысле SilverLight был бы отличным практическим применением этого, если бы SilverLight не решил вообще не использовать CAS в конце.
Хостинг-провайдеры
Места, где вы видите это в действии там, где необходима защищенная среда: конечно, сам ASP.NET, но провайдеры хостинга ASP.NET используют модифицированную модель безопасности для предотвращения вторжений в свои драгоценные системы. Я точно знаю, что Webhost4Life использует это (на их сайте нет информации об этом, но я работал с ними, это действительно есть). Если посмотреть дальше, то же самое делают и другие провайдеры хостинга ASP.NET но они также не очень ясны по этому поводу: ветка на godaddy.com не желает изменить CAS (и нет ясности, что поддерживается, а что нет) или это связанное обсуждение 1 & 1 . Некоторые сайты облачного хостинга (rackspacecloud) пошли дальше и «работали с Microsoft над измененным уровнем полного доверия» , каким бы он ни был.
Вкратце: если вы найдете хост ASP.NET, скорее всего, они использовали CAS, чтобы помешать вам делать то, что они не хотят, чтобы вы делали. Они даже могут использовать его, чтобы сделать разницу между "базовым" (со многими ограничениями) хостингом и "корпоративным" (с небольшими ограничениями) хостингом, что придает совершенно другое значение CAS.
Другие приложения CAS
Так много для немногих реальных - мировые ситуации, с которыми я столкнулся сам. В моем недавнем проекте было нечто похожее: разрешить пользователю загрузить библиотеку и протестировать ее на производительность («кто делает лучший алгоритм»). Излишне говорить, что CAS нам очень нужен был. Другие примеры или интересные ресурсы:
- NAR Loader (приложение codeproject) использует собственный CAS
- LR Evaluator (также приложение codeproject) использует CAS
- ClickOnce (см. Ниже) использует CAS
- Шаблоны проектирования CAS : популярность «предполагает» использование CAS
- Понимание CAS : еще большая популярность и некоторые комментарии подразумевают приложения
- Microsoft SharePoint полностью использует CAS кажется (извините, я не специалист по SP)
Для любой ситуации, когда вы просто полностью контролируете себя, вы создаете собственное приложение и код (или уже создали его) и полностью контролируете свою систему, я не думаю, что вам понадобится CAS слишком часто. Это больше то, что вы бы использовали в ту минуту, когда у вас есть возможность запустить код из менее надежных источников (а это практически все, что не находится под вашим полным контролем).
CAS vs ClickOnce
Настройки CAS по умолчанию ограничивают возможности запуска кода из сетевой ресурс или другие нелокальные источники. Это имеет смысл, но строгие ограничения затрудняют создание центрального репозитория для распределенного приложения. .NET 2.0 представил ClickOnce, который должен был повысить безопасность ( обсуждение здесь ).
Сам ClickOnce использует CAS , чтобы программа установки не вызывала системные функции. Как таковой, Я считаю, что это, пожалуй, самое известное приложение, основанное на CAS .
Суть в том, что вам нужно понимать CAS, чтобы иметь возможность создавать что-то, что может запускаться непосредственно из общего ресурса, или вы проигнорируете это all и используйте ClickOnce.
Опрос Microsoft по CAS
В 2005 году Microsoft провела опрос , чтобы выяснить, почему CAS был так непопулярен, в надежде улучшить его, чтобы сделать его более применимым. К сожалению, я не смог найти фактических результатов опроса, кроме этого поста, в котором несколько подробно объясняется, почему CAS используется недостаточно.
CAS в другом мире
Этот пост, однако, указывает на интригующую нишу: CAS применяется в другом мире: Unix / Linux. Они не называют это CAS, вместо этого это BitFrost . Как это для реального приложения: "
Я был руководителем разработки проекта, чтобы получить Сертификация JITC (Министерство обороны США) для решения на основе .NET, и настройки CAS были очень тщательно изучены во время сертификационного тестирования.
Как и большинство других требований сертификации, код мог использовать только привилегии, необходимые для работы, и не более того.
Если вы планируете получить сертификаты безопасности, CAS определенно может быть важен.
Мы использовали CAS для наших приложений, это было не так уж сложно, поскольку мы всего лишь пытались остановить выполнение неавторизованного кода. Проблемы возникли однажды при использовании нашего программного обеспечения из локальной сетевой папки, но политика cas устранила проблему.
- Мы защитили все наши сборки, используя строгое имя.
- Мы создали политику cas для всех сборок с помощью нашей сильной имя и разрешенный код, подписанный нашим строгим именем, для запуска из локальной сети и локально размещенного кода.
- Сборки, загруженные из локальной сети, нуждающиеся в доступе к локальным файлам (компонент для записи компакт-дисков с данными), необходим для получения атрибута запроса ссылки для всех общедоступных классов.
После обновления .NET3.5 наши проблемы больше не существовали, поскольку код в локальной сети теперь обрабатывается как локальный код.
Примечание для читателя: см. Два комментария ниже; похоже, что я случайно раздул определение CAS, чтобы (неправильно) включить RBS. Я оставлю здесь ответ для справки, но обратите внимание на различие.
У CAS есть два недостатка; то, что вы больше всего увидите в на этом экзамене , - это все нюансы для кода, вызывающего другой код, который может быть полезным для частичного доверия, но в большинстве случаев это просто боль - и хуже того: если ваш код полностью доверяет (что в большинстве / слишком много) ни один из них на самом деле не выполняет (полностью пропускается).
полезная часть из CAS RBS - это основное разрешение, которое используется ; конечно, ваш пользовательский интерфейс должен проверять доступ к функциям, но вы можете указать (в своей логике):
[PrincipalPermission(SecurityAction.Demand, Role = "ADMIN")]
static void DeleteOrder(int id) { ... }
Это будет соблюдаться даже при полном доверии; вы можете определить своего собственного принципала (привязанного к пользователю), реализовав IPrincipal (см. IsInRole () ). А поскольку принципалы поддерживаются в большинстве сред (winforms, webforms, mvc, wcf и т. Д.), Это может стать очень гибким способом двойной проверки безопасности на бизнес-уровне без необходимости ссылаться на конкретную модель безопасности . Обратите внимание, что приведенная выше проверка будет работать в любой среде .
Вы также можете использовать ее для управления своим пользовательским интерфейсом. У меня был пост в usenet, который включал / отключал элементы управления winforms на основе принципала (с использованием свойств времени выполнения для указания роли для каждого элемента управления, что-то вроде ToolTip и т. Д.) - Я не могу найти его в данный момент, хотя (редактировать: может быть этот ).
IPrincipal (см. IsInRole () ). А поскольку принципалы поддерживаются в большинстве сред (winforms, webforms, mvc, wcf и т. Д.), Это может стать очень гибким способом двойной проверки безопасности на бизнес-уровне без необходимости ссылаться на конкретную модель безопасности . Обратите внимание, что вышеуказанная проверка будет работать в любой среде .
Вы также можете использовать ее для управления своим пользовательским интерфейсом. У меня был пост в usenet, который включал / отключал элементы управления winforms на основе принципала (с использованием свойств времени выполнения для указания роли для каждого элемента управления, что-то вроде ToolTip и т. Д.) - Я не могу найти его в данный момент, хотя (редактировать: может быть этот ).
IPrincipal (см. IsInRole () ). А поскольку принципалы поддерживаются в большинстве сред (winforms, webforms, mvc, wcf и т.д.), это может сделать очень гибкий способ двойной проверки безопасности на бизнес-уровне без необходимости ссылаться на конкретную модель безопасности . Обратите внимание, что вышеуказанная проверка будет работать в любой среде .
Вы также можете использовать ее для управления своим пользовательским интерфейсом. У меня был пост в usenet, который включал / отключал элементы управления winforms на основе принципала (с использованием свойств времени выполнения для указания роли для каждого элемента управления, что-то вроде ToolTip и т. Д.) - Я не могу найти его в данный момент, хотя (редактировать: может быть этот ).
Вы также можете использовать ее для управления своим пользовательским интерфейсом. У меня был пост в usenet, который включал / отключал элементы управления winforms на основе принципала (с использованием свойств времени выполнения для указания роли для каждого элемента управления, что-то вроде ToolTip и т. Д.) - Я не могу найти его в данный момент, хотя (редактировать: может быть этот ).
Вы также можете использовать ее для управления своим пользовательским интерфейсом. У меня был пост в usenet, который включал / отключал элементы управления winforms на основе принципала (с использованием свойств времени выполнения для указания роли для каждого элемента управления, что-то вроде ToolTip и т. Д.) - я не могу найти его в данный момент, хотя (редактировать: может быть этот ).
Вы также можете использовать это для управления своим пользовательским интерфейсом. У меня был пост в usenet, который включал / отключал элементы управления winforms на основе принципала (с использованием свойств времени выполнения для указания роли для каждого элемента управления, что-то вроде ToolTip и т. Д.) - я не могу найти его в данный момент, хотя (редактировать: может быть этот ).
Вы также можете использовать это для управления своим пользовательским интерфейсом. У меня был пост в usenet, который включал / отключал элементы управления winforms на основе принципала (с использованием свойств времени выполнения для указания роли для каждого элемента управления, что-то вроде ToolTip и т. Д.) - я не могу найти его в данный момент, хотя (редактировать: может быть этот ).
Технически это очень полезно, поскольку позволяет очень детально указать разрешения. Это хорошо как для вас (поскольку теоретически это значительно усложняет использование уязвимостей системы безопасности - даже если злоумышленник получает полный контроль над вашим приложением, он все еще заблокирован в песочнице CAS), так и для вашего клиента (поскольку они могут видеть, что именно вы приложение может проводить и запускать собственный аудит безопасности)
На практике это в основном бессмысленно. Я думаю, что это слишком сложно, слишком мало поддерживается доступными инструментами разработчика, и большинству пользователей все равно.
Конечно, есть исключения (правительства и клиенты, которые действительно знают .net / CAS), и я хотел бы сказать, что CAS абсолютно полезен и обязателен, но реальность говорит на понятном языке.
В отношении безопасности доступа к коду необходимо понимать то, что разработчику приложения от нее очень мало пользы, кроме понимания того, как она используется и на каком уровне разрешений для API, которые вы может звонить. Единственное исключение из этого, которое я действительно нашел полезным, - это CAS с именем PrincipalPermission, он в основном не позволяет выполнять определенный код, если правильная роль не определена для текущего участника. См. Эту публикацию на нем:
http://www.coderjournal.com/2008/03/securing-mvc-controller-actions/
Разработчики, которым действительно нужно обратить внимание на CAS и как это должно быть реализовано в их приложении есть разработчики фреймворка и библиотеки кода. Потому что есть определенные уровни доверия, которые вам нужно требовать для того, чтобы ваше приложение работало, особенно при работе с неуправляемыми ресурсами, такими как файлы, сетевые потоки, последовательные порты и т. Д. Или если вы создаете код для этого неуправляемого ресурса, например, некоторые специальные сервер, или любой вид низкоуровневого доступа к вашим сборкам, вы захотите создать вокруг него некоторую защиту доступа к коду, чтобы людям не разрешалось выполнять что-то, что им строго запрещено.
Это не помогает что Microsoft действительно не проделала такой большой работы, объясняя, как CAS следует использовать в повседневных приложениях. Так что это действительно причина отсутствия использования. Однако CAS - одна из многих причин того, что .NET является таким безопасным языком и страдает гораздо меньшим количеством проблем, чем его конкуренты.
или любой вид низкоуровневого доступа к вашим сборкам, вы захотите создать вокруг него некоторую защиту доступа к коду, чтобы людям не разрешалось выполнять то, что им строго запрещено.Это не помогает, что Microsoft на самом деле не сделал такой большой работы, объясняя, как CAS следует использовать в повседневных приложениях. Так что это действительно причина отсутствия использования. Однако CAS является одной из многих причин того, что .NET является таким безопасным языком и страдает гораздо меньшим количеством проблем, чем его конкуренты.
или любой вид низкоуровневого доступа к вашим сборкам, вы захотите создать вокруг него некоторую защиту доступа к коду, чтобы людям не разрешалось выполнять то, что им строго запрещено.Это не помогает, что Microsoft на самом деле не сделал такой большой работы, объясняя, как CAS следует использовать в повседневных приложениях. Так что это действительно причина отсутствия использования. Однако CAS является одной из многих причин того, что .NET является таким безопасным языком и страдает гораздо меньшим количеством проблем, чем его конкуренты.
Я действительно проделал огромную работу, объясняя, как CAS следует использовать в повседневных приложениях. Так что это действительно причина отсутствия использования. Однако CAS - одна из многих причин того, что .NET является таким безопасным языком и страдает гораздо меньшим количеством проблем, чем его конкуренты. Я действительно проделал огромную работу, объясняя, как CAS следует использовать в повседневных приложениях. Так что это действительно причина отсутствия использования. Однако CAS - одна из многих причин того, что .NET является таким безопасным языком и страдает гораздо меньшим количеством проблем, чем его конкуренты.Хотя я никогда не использовал его, мое понимание CAS заключалось в том, что его также можно использовать для расширения механики объектно-ориентированного проектирования. Например, предположим, что вы разрабатываете пакет массового доступа к данным для банка, который должен реализовать доступ к базе данных и кэширование. Несмотря на то, что они являются частью одного и того же пакета развертывания, учитывая гипотетический размер проекта, логика должна быть реализована в отдельных сборках, поскольку они представляют собой достаточно разные наборы задач, которые зависят от разных внешних факторов (инфраструктура базы данных или использование потребителями).
Однако коду кэширования может потребоваться доступ к некоторым конфиденциальным классам или методам в сборке доступа к данным, к которым потребители всего пакета не должны иметь доступа. Следовательно, эти классы и методы доступа к данным не могут быть просто общедоступными . Защищенные методы в сборке доступа к данным с подклассами в сборке кэширования могут обойтись в некоторых случаях, но часто это злоупотребление наследованием. Было бы просто более элегантно оставить их общедоступными с LinkDemands, размещенными у вызывающих для настраиваемого Разрешения (например, DataPackagePermisson ), которое администраторы будут предоставлять только кэширующей сборке.
Одна вещь, которую вы должны знать, - это то, что защита доступа к коду в значительной степени нарушена как метод защиты от несанкционированного доступа. См .:
...
На безопасность доступа для кода больше нельзя полагаться, чтобы предотвратить использование измененных сборок в поставляемых продуктах. Это означает, что если ваше приложение зависит от безопасности доступа кода для выполнения проверок лицензирования, злоумышленнику будет тривиально заменить вашу лицензионную сборку другой, тем самым получив бесплатный доступ к вашему приложению.
...