Предоставляют ли уровни доступа и модификаторы (закрытые, закрытые и т.д.) Функции безопасности на С#?

Я видел, что вы можете манипулировать частным и внутренним членами, используя отражение. Я также видел, что он сказал, что "запечатанный" класс более безопасен, чем тот, который не является.

Являются ли модификаторы "общедоступными, защищенными, внутренними, частными, абстрактными, запечатанными, readonly" чем-то большим, чем джентльменское соглашение о дизайне и использовании API, которое может быть нарушено до тех пор, пока у вас есть доступ к размышлению? И если у хакера уже есть код, который вызывает ваш API, игра уже потеряна, правильно?

Является ли следующее безопаснее, чем любой другой класс?

//private class
sealed class User
{
    private string _secret = "shazam";
    public readonly decimal YourSalary;
    public string YourOffice{get;};
    private DoPrivilegedAction()
    {
    }
}

Ответ 1

Во-первых, чтобы ответить на ваш вопрос: система безопасности предназначена для защиты ХОРОШИХ ПОЛЬЗОВАТЕЛЕЙ от BAD CODE; он явно не предназначен для защиты ХОРОШЕГО КОДА от BAD USERS. Ограничения доступа уменьшают атаки ваших пользователей на частично доверенный код. Они не уменьшают атаки на ваш код от враждебных пользователей. Если угроза - это враждебные пользователи, получающие ваш код, тогда у вас есть большая проблема. Система безопасности не уменьшает эту угрозу вообще.

Во-вторых, чтобы ответить на некоторые из предыдущих ответов: понимание полной взаимосвязи между отражением и безопасностью требует пристального внимания к деталям и хорошего понимания деталей системы CAS. Ранее опубликованные ответы, в которых утверждается, что нет связи между безопасностью и доступом из-за отражения, вводят в заблуждение и ошибочны.

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

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

Во-вторых, в новой модели безопасности .NET предположим, что сборке A предоставляется надмножество набора грантов сборки B системой CAS. В этом сценарии код в сборке A разрешен для использования отражения для наблюдения внутренних элементов B.

В-третьих, все становится очень сложным, когда вы добавляете динамически генерируемый код в микс. Объяснение того, как работает "Пропускаемость видимости" и "Ограниченная пропускная способность", и то, как они изменяют взаимодействие между отражением, контролем доступа и системой безопасности в сценариях, где кодекс плюется во время выполнения, потребует больше времени и пространства, чем я есть. См. Блог Shawn Farkas, если вам нужны детали.

Ответ 2

Модификаторы доступа - это не безопасность, а хороший дизайн. Правильные уровни доступа для классов и методов приводят/обеспечивают хорошие принципы проектирования. Отражение должно, в идеале, использоваться только тогда, когда удобство его использования обеспечивает большую полезность, чем стоимость нарушения (если таковая существует) наилучших методов проектирования. Классы уплотнения служат только для того, чтобы разработчики не расширяли ваш класс и не нарушали его функциональность. Существуют разные мнения о полезности классов уплотнения, но поскольку я делаю TDD и трудно издеваться над закрытым классом, я избегаю его как можно больше.

Если вам нужна безопасность, вам необходимо следовать правилам кодирования, которые предотвращают попадание плохих парней и/или защиту конфиденциальной информации от проверки, даже если происходит перерыв. Предотвращение вторжений, обнаружение вторжений, шифрование, аудит и т.д. - вот некоторые из инструментов, которые необходимо использовать для защиты вашего приложения. Настройка ограничительных модификаторов доступа и классов уплотнения имеет мало общего с безопасностью приложений, IMO.

Ответ 3

Нет. Они не имеют никакого отношения к безопасности. Отражение разбивает их всех.

Ответ 4

Что касается комментариев об отражении и безопасности, считайте, что в mscorlib.dll есть много внутренних типов + членов, которые вызывают собственные функции Windows и могут потенциально привести к плохому, если вредоносное приложение использует отражение для вызова в них. Это не обязательно проблема, так как ненадежным приложениям обычно не предоставляются эти разрешения во время выполнения. Это (и несколько декларативных проверок безопасности) заключается в том, как двоичный файл mscorlib.dll может выставлять свои типы во всевозможный доверенный и ненадежный код, однако ненадежный код не может обойти открытый API.

Это действительно просто царапает поверхность проблемы с отражением + безопасности, но, надеюсь, достаточно информации, чтобы вести вас по правильному пути.

Ответ 5

Я всегда пытаюсь заблокировать все до минимального требуемого доступа. Как сказал tvanfosson, это действительно касается дизайна больше, чем безопасности.

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

При этом разработчик может использовать отражение, чтобы фактически создать экземпляр нового типа реализации. Там ничего не мешает. Тем не менее, я могу отдохнуть, зная, что я сделал это, по крайней мере, несколько сложно, чтобы нарушить дизайн.