Уровни доступа и модификаторы (закрытый, закрытый и т. Д.) Служат целям безопасности в C #?

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

Нет. Это не имеет ничего общего с безопасностью. Отражение разбивает их всех.

Answer 4

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

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

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

Answer 5

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

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