Может ли выполнение «проверки безопасности» .NET привести к ошибкам безопасности? - PullRequest
Новая
       52

Может ли выполнение «проверки безопасности» .NET привести к ошибкам безопасности?

0 голосов
/ 28 ноября 2011

У меня есть фрагмент кода: 

public void MyMethod()
{
   DirectoryEntry de; 
   ...
   de.AuthenticationType = AuthenticationTypes.Secure;
   ...
}

, который FxCop задыхается на :

CA2122: не подвергать косвенному представлению методы с требованиями ссылки

Разрешение : MyMethod() вызывает DirectoryEntry.AuthenticationType.set(AuthenticationTypes) с LinkDemand.
При выполнении этого вызова DirectoryEntry.AuthenticationType.set(AuthenticationTypes) косвенно подвергается воздействию кода пользователя.

Информация : Не переносите метод, защищенный LinkDemand, методом, который не выполняет проверку безопасности.LinkDemand проверяет разрешения непосредственного абонента, а не проверяет разрешения всех абонентов в стеке вызовов.В этом случае будут проверены разрешения метода-оболочки.Если метод-обертка сам по себе не проверяет разрешения вызывающих абонентов выше в стеке вызовов, злонамеренный код может выполнить упакованную функцию, даже если у него нет разрешения для этого. "

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

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

Если я добавлю "проверку безопасности * к MyMethod, есть ли возможностьтот код, который работает в данный момент, перестанет работать?

i предположим , что код, как написано сейчас, будет не работать, если у кого-то нет разрешения,Другими словами: 

directoryEntry.AuthenticationType = AuthenticationTypes.Secure

будет уже потерпеть неудачу , если у кого-то нет правильных "разрешений".Добавление «проверки безопасности» выше в стек вызовов не изменит этого факта - только вызовет сбой раньше.В этом случае добавьте проверку безопасности в порядке.

С другой стороны, если: 

public void MyMethod() {...}

MyMethod();

в настоящее время работает, но 

[SecurityCheck(...)]
public void MyMethod() {...}

AD.MyMethod()

будет begin потерпеть неудачу, тогда я не могу добавить его.

Особенно в коде библиотеки, который все используют.

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

Это похоже на то, когда большинство людей проверяют учетные данные в активном каталоге, пытаясь подключиться к AD с помощью имени пользователя и пароля и прочитать свойство .Возможно, вам не будет разрешено 1073 * читать свойства, даже если имя пользователя / пароль верны.Держу пари, что никто, кроме меня, не знает, как настроить ActiveDirectory для репликации этого случая сбоя.

В моем случае, я полагаю, никто не знает, как настроить что-то, чтобы обеспечить безопасность кода.

1 Ответ

0 голосов
/ 28 ноября 2011

Я предполагаю, что код, как написано сейчас, не будет работать, если у кого-то нет разрешения

Это не так для LinkDemand, который требует только непосредственного вызывающего абонентацелевое разрешение (я).По этой причине FxCop предупреждает вас о потенциальной проблеме: злонамеренный вызывающий объект может потенциально использовать ваш метод для косвенного вызова метода DirectoryEntry, несмотря на то, что у него недостаточно разрешений CAS, чтобы сделать это самостоятельно.

Лучшее решение для этогозависит от нескольких вещей, в том числе от того, какую версию .NET Framework вы используете.Для более ранних версий .NET добавьте LinkDemand или полный спрос на неограниченную DirectoryServicesPermission к вашему методу.Если FxCop доволен, вы в значительной степени покончили с этой конкретной проблемой.Однако возможно, что некоторые вызывающие абоненты больше не смогут вызывать ваш метод.Если это проблема, вам нужно оценить ваше использование DirectoryEntry и определить, может ли он быть использован злонамеренным пользователем перед тем, как снимать защиту.

В более поздних версиях .NET все становится сложнее.Если вам нужна помощь в этом, укажите, на какую версию (ы) .NET вы ориентируетесь и считаете ли вы необходимым поддерживать частично доверенных абонентов.

...