Уровни доступа и модификаторы (частный, изолированный, и т.д.) служат цели безопасности в C#?
Вы также можете сделать следующее:
[myArray addObject:[NSValue valueWithCGPoint:MyCGPoint]];
5 ответов
Во-первых, отвечу на ваш вопрос: система безопасности предназначена для защиты ХОРОШИХ ПОЛЬЗОВАТЕЛЕЙ от ПЛОХОГО КОДА ; он явно не предназначен для защиты ХОРОШИЙ КОД от ПЛОХОГО ПОЛЬЗОВАТЕЛЯ . Ваши ограничения доступа смягчают атаки на ваших пользователей с помощью частично доверенного враждебного кода . Они не предотвращают атак на ваш код со стороны враждебных пользователей . Если угроза заключается в том, что враждебно настроенные пользователи получают ваш код, то у вас большая проблема. Система безопасности совсем не снижает эту угрозу.
Во-вторых, чтобы ответить на некоторые из предыдущих ответов: понимание полной взаимосвязи между отражением и безопасностью требует внимательного внимания к деталям и хорошего понимания деталей системы CAS. Ранее опубликованные ответы, в которых говорится об отсутствии связи между безопасностью и доступом из-за отражения, вводят в заблуждение и неверны.
Да, отражение позволяет вам переопределить ограничения «видимости» (иногда). Это не означает, что нет связи между доступом и безопасностью. Связь заключается в том, что право на использование отражения для отмены ограничений доступа глубоко связано с системой CAS множеством способов.
Во-первых, для того, чтобы делать это произвольно , коду должно быть предоставлено разрешение на частное отражение. по системе CAS. Обычно это предоставляется только полностью доверенному коду, который, в конце концов, уже может делать что угодно .
Во-вторых, в новой модели безопасности .NET предположим, что сборке A предоставляется расширенный набор разрешений сборки B системой CAS. В этом сценарии коду в сборке A разрешено использовать отражение для наблюдения за внутренним устройством B.
В-третьих, все становится действительно довольно сложным, когда вы добавляете в смесь динамически сгенерированный код. Объяснение того, как работает «Пропуск видимости» и «Ограниченная видимость пропуска», и как они меняют взаимодействие между отражением, контролем доступа и системой безопасности в сценариях, где код воспроизводится во время выполнения, займет у меня больше времени и места, чем у меня есть в наличии. Если вам нужны подробности, смотрите блог Шона Фаркаса.
и то, как они изменяют взаимодействие между отражением, контролем доступа и системой безопасности в сценариях, когда код выплевывается во время выполнения, отнимет у меня больше времени и места, чем у меня есть. Если вам нужны подробности, смотрите блог Шона Фаркаса. и то, как они изменяют взаимодействие между отражением, контролем доступа и системой безопасности в сценариях, когда код выплевывается во время выполнения, отнимет у меня больше времени и места, чем у меня есть. Если вам нужны подробности, смотрите блог Шона Фаркаса.Модификаторы доступа касаются не безопасности, а хорошего дизайна. Правильные уровни доступа для классов и методов стимулируют / обеспечивают соблюдение хороших принципов проектирования. В идеале отражение следует использовать только тогда, когда удобство его использования дает больше пользы, чем цена нарушения (если таковая имеется) лучших практик проектирования. Запечатывание классов служит только цели предотвращения того, чтобы разработчики расширили ваш класс и "нарушили" его функциональность. Существуют разные мнения о полезности запечатывающих классов, но поскольку я использую TDD, и сложно имитировать запечатанный класс, я стараюсь избегать этого в максимально возможной степени.
Если вам нужна безопасность, вам нужно следовать методам кодирования, которые предотвращают злоумышленники не могут проникнуть внутрь и / или защитить конфиденциальную информацию от проверки, даже если произойдет взлом. Предотвращение вторжений, обнаружение вторжений, шифрование, аудит и т. д. - вот некоторые из инструментов, которые вам нужно использовать для защиты вашего приложения. Установка модификаторов ограниченного доступа и классов запечатывания имеет мало общего с безопасностью приложений, IMO.
Нет. Это не имеет ничего общего с безопасностью. Отражение их всех разбивает.
Относительно комментариев об отражении и безопасности - учтите, что в mscorlib.dll есть много внутренних типов + членов, которые вызывают собственные функции Windows и потенциально могут привести к неисправности, если вредоносное приложение использует отражение для позвоните им. Это не обязательно проблема, поскольку ненадежным приложениям обычно не предоставляются эти разрешения во время выполнения. Это (и несколько декларативных проверок безопасности) - как двоичный файл mscorlib.dll может открывать свои типы для любого доверенного и ненадежного кода, но при этом ненадежный код не может обойти общедоступный API.
Это действительно просто царапина поверхность отражения + проблема безопасности, но, надеюсь, этой информации достаточно, чтобы вести вас по правильному пути.
Я всегда стараюсь ограничить доступ к минимальному уровню. Как заявил Тванфоссон, на самом деле дизайн больше, чем безопасность.
Например, я сделаю интерфейс общедоступным, а мои реализации внутренними, а затем публичный класс / методы фабрики для получения реализаций. Это в значительной степени вынуждает потребителей всегда вводить его как интерфейс, а не реализацию.
При этом разработчик может использовать отражение для фактического создания экземпляра нового типа реализации. Ничто его не останавливает. Тем не менее, я могу отдыхать, зная, что я сделал, по крайней мере, несколько трудным нарушение дизайна.