Как написать программу безопасности

После того, как сформулирована политика безопасности , можно приступать к составлению программы ее реализации и собственно к реализации.

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

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

• управление рисками ( оценка рисков , выбор эффективных средств защиты);
• координация деятельности в области информационной безопасности, пополнение и распределение ресурсов;
• стратегическое планирование ;
• контроль деятельности в области информационной безопасности.

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

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

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

Цель программы нижнего уровня — обеспечить надежную и экономичную защиту конкретного сервиса или группы однородных сервисов. На этом уровне решается, какие следует использовать механизмы защиты; закупаются и устанавливаются технические средства; выполняется повседневное администрирование ; отслеживается состояние слабых мест и т.п. Обычно за программу нижнего уровня отвечают администраторы сервисов.

Синхронизация программы безопасности с жизненным циклом систем

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

В жизненном цикле информационного сервиса можно выделить следующие этапы:

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

Закупка . На данном этапе составляются спецификации, прорабатываются варианты приобретения, выполняется собственно закупка .

Что могут хакеры? В школе такому точно не научат. Профессионалы..

Установка . Сервис устанавливается, конфигурируется, тестируется и вводится в эксплуатацию .

Эксплуатация . На данном этапе сервис не только работает и администрируется, но и подвергается модификациям.

Выведение из эксплуатации . Происходит переход на новый сервис.

Рассмотрим действия, выполняемые на каждом из этапов, более подробно.

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

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

• какого рода информация предназначается для обслуживания новым сервисом?
• каковы возможные последствия нарушения конфиденциальности, целостности и доступности этой информации?
• каковы угрозы, по отношению к которым сервис и информация будут наиболее уязвимы?
• есть ли какие-либо особенности нового сервиса (например, территориальная распределенность компонентов), требующие принятия специальных процедурных мер?
• каковы характеристики персонала, имеющие отношение к безопасности (квалификация, благонадежность)?
• каковы законодательные положения и внутренние правила, которым должен соответствовать новый сервис?

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

Этап закупки — один из самых сложных. Нужно окончательно сформулировать требования к защитным средствам нового сервиса, к компании, которая может претендовать на роль поставщика, и к квалификации, которой должен обладать персонал, использующий или обслуживающий закупаемый продукт. Все эти сведения оформляются в виде спецификации, куда входят не только аппаратура и программы, но и документация, обслуживание, обучение персонала. Разумеется, особое внимание должно уделяться вопросам совместимости нового сервиса с существующей конфигурацией. Подчеркнем также, что нередко средства безопасности являются необязательными компонентами коммерческих продуктов, и нужно проследить, чтобы соответствующие пункты не выпали из спецификации.

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

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

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

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

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

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

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

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

Источник: intuit.ru

Рекомендации по безопасности для C++

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

Средства безопасности в Visual C++

Эти функции безопасности встроены в компилятор Microsoft C++ и компоновщик:

/guard (Включение защиты потока управления)
Заставляет компилятор анализировать поток управления для целевых объектов непрямого вызова во время компиляции, а затем вставлять код для проверки целевых объектов во время выполнения.

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

/SAFESEH (Образ имеет безопасные обработчики исключений)
Указывает компоновщику на необходимость включения в выходной образ таблицы, содержащей адрес каждого обработчика исключений. Во время выполнения операционная система проверяет по этой таблице, действительно ли используются только допустимые обработчики исключений. Это помогает предотвратить запуск обработчиков исключений, внедряемых злоумышленниками в среду выполнения. По умолчанию этот параметр выключен.

/NXCOMPAT , /NXCOMPAT (совместимо с предотвращением выполнения данных) Эти параметры компилятора и компоновщика обеспечивают совместимость с функцией защиты от выполнения данных (DEP). Функция DEP защищает ЦП от исполнения страниц, не содержащих кода.

/analyze (Анализ кода)
Этот параметр компилятора запускает анализ кода с целью выявления потенциальных проблем безопасности, таких как переполнение буфера, отмена инициализации памяти, разыменование нулевого указателя и утечки памяти. По умолчанию этот параметр выключен. Дополнительные сведения см. в статье Анализ кода для C/C++ Обзор.

/DYNAMICBASE (Использование рандомизации макета адресного пространства)
Этот параметр компоновщика позволяет собрать исполняемый образ, который можно загрузить в другое расположение в памяти в начале выполнения. Этот параметр также делает расположение стека в памяти значительно менее прогнозируемым.

Среда выполнения повышенной безопасности

В библиотеку времени выполнения C (CRT) были добавлены безопасные версии функций, которые могут создать угрозу безопасности, например функция копирования непроверенной строки strcpy . Поскольку устаревшие, небезопасные версии этих функций использовать не рекомендуется, во время компиляции они выводят предупреждения. Рекомендуется использовать безопасные версии этих функций CRT, а не подавлять вывод предупреждений компилятора. Дополнительные сведения см. в разделе Функции безопасности в CRT.

Библиотека SafeInt

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

Класс SafeInt защищает от ошибок переполнения емкости целочисленных переменных и деления на нуль, которые могут использоваться в злонамеренных целях. Его можно использовать для обработки сравнений значений различных типов. Он предоставляет две политики обработки ошибок.

Политика по умолчанию класса SafeInt заключается в выдаче исключения класса SafeIntException , сообщающего о причинах невозможности выполнения математической операции. Вторая политика заключается в том, что класс SafeInt останавливает выполнение программы. Также можно определить пользовательскую политику.

Каждая функция класса SafeInt защищает от злонамеренного использования ошибок одной из математических операций. Можно использовать параметры двух различных типов без преобразования их к одному типу. Для защиты множества математических операций используйте класс SafeInt .

Checked Iterators

Проверяемый итератор обеспечивает принудительное соблюдение ограничений контейнера. По умолчанию при превышении ограничений проверяемого итератора создается исключение, и выполнение программы прекращается. Проверенный итератор предоставляет другие уровни ответа, зависящие от значений, назначенных препроцессору, например _SECURE_SCL_THROWS и _ITERATOR_DEBUG_LEVEL . Например, в _ITERATOR_DEBUG_LEVEL=2 проверяемый итератор обеспечивает комплексные проверки правильности в режиме отладки, которые становятся доступными с помощью утверждений. Дополнительные сведения см. в разделе Проверенные итераторы и _ITERATOR_DEBUG_LEVEL .

Анализ управляемого кода

Инструмент анализа управляемого кода, также известный как FxCop, выполняет проверку сборок на соответствие рекомендациям, изложенным в Правилах разработки приложений платформы .NET Framework. FxCop анализирует код и метаданные в каждой сборке и выявляет дефекты по следующим направлениям:

• Разработка библиотек
• Локализация
• Соглашения об именах
• Производительность
• Безопасность

Средство проверки приложений Windows

Средство проверки приложений (AppVerifier) помогает выявлять потенциальные проблемы совместимости, стабильности и безопасности приложений.

Средство AppVerifier контролирует использование операционной системы приложением. Он следит за файловой системой, реестром, памятью и API-интерфейсами во время работы приложения, а при обнаружении ошибок выдает рекомендации по исправлению исходного кода.

Можно использовать AppVerifier в следующих целях:

• Тестирование приложения на наличие возможных проблем совместимости, возникающих в результате типичных ошибок программирования.
• Исследовать приложения для определения утечек памяти.
• Выявлять потенциальные проблемы безопасности в приложениях.

Учетные записи пользователей Windows

Для разработчиков и в конечном счете пользователей использование учетных записей Windows, относящихся к группе «Администраторы», создает повышенный риск для безопасности. Дополнительные сведения см. в разделах Запуск от имени члена группы «Пользователи» и Как контроль учетных записей (UAC) влияет на приложение.

Руководство по спекулятивным каналам выполнения на стороне

Сведения о том, как определить и устранить уязвимости аппаратного канала спекулятивного выполнения в программном обеспечении C++, см. в руководстве разработчика C++ по спекулятивным каналам выполнения.

Источник: learn.microsoft.com

Пуленепробиваемый C#: основные правила создания безопасного кода

Сегодня мы поговорим о том, о чем вспоминают обычно в последнюю очередь — о
безопасности твоих приложений. Ведь ты же не хочешь читать о том, что в творении
рук твоих — супернавороченной программе — нашли уязвимости, которые поставят под
угрозу работу каких-нибудь важных организаций? Ладно бы, если это простая фирма,
а если банк? Или атомная электростанция?

Введение

Увы и ах — технологии .NET прочно вошли в нашу жизнь, и на сегодняшний день
разработчики C# пользуются неслыханной популярностью на рынке труда. Легкий в
изучении и освоении язык дал программисту неслыханную свободу действий и при
этом позволил расширить круг тех лиц, которые стали гордо именовать себя
«программистами». Столь низкий «порог вхождения в специальность» обусловил тот
факт, что начинающие (и не очень) программисты не стали уделять должного
внимания безопасности своего кода. Но обо всем по порядку.

У общеязыковой исполняющей среды (common language runtime, CLR) в .NET
Framework есть своя модель безопасного выполнения кода, независимая от
ограничений операционной системы, в которой она работает. Более того, в отличие
от старой модели защиты на основе участников безопасности (principal-based
security), CLR реализует политику, исходя из того, откуда поступает код, а не из
того, кто являет ся его пользователем. Эта модель защиты по правам доступа кода
(code access security) имеет больший смысл в современных условиях, поскольку
немалая часть кода устанавливается через интернет, и даже доверенный
пользователь (trusted user) не знает, какой код действительно безопасен. Все это
реализовано в пространстве имен System.Security. «Ээээээ, так ты об этом. » —
разочарованно вздохнет читатель, который, наверняка, вдоль и поперек изучил все
те фичи, которые .NET предлагает программисту для реализации его злобных
замыслов. Спешу огорчить — о System.Security мы сегодня как раз разговаривать не
будем. Это скучно :). Вместо этого мы попробуем взглянуть на проблему
«безопасного кода» с другой стороны — с точки зрения того, в чьи хорошие (или не
очень) руки он попадет. Вне зависимости от того, что предоставляет интерфейс
твоей программы: просто складывает два числа или же управляет атомной
электростанцией.

Что может CLR?

Общеязыковая исполняющая среда (common language runtime, CLR) и Microsoft .NET
Framework предоставляют всем приложениям с управляемым кодом защиту на основе
признаков — это так называемая evidence-based security. В большинстве случаев
при написании кода обеспечивать защиту явным образом не требуется. Тем не менее,
я попытаюсь кратко рассмотреть вопросы безопасности, которые тебе, как
мегакрутому программисту, возможно, понадобится учитывать при написании кода, и
описать те принципы классификации компонентов, позволяющие определить, что нужно
предпринять для гарантированной защиты кода.

Для защиты управляемого кода используются две технологии:

• защита на основе признаков (evidence-based security) позволяет
  определять, какие разрешения следует предоставлять коду;
• защита по правам доступа кода (code access security) позволяет
  проверять, весь ли код в стеке имеет необходимые разрешения на выполнение
  каких-либо действий.

Эти две технологии связаны между собой концепцией разрешений.

По признакам и политике безопасности, устанавливаемой администратором,
система защиты определяет, какие разрешения могут быть выданы коду. Программа
сама может запрашивать какое-либо разрешение, влияя на состав окончательного
набора разрешений. Запрос разрешения выражается в виде объявления на уровне
сборки с синтаксисом пользовательских (custom) атрибутов. Однако, в любом
случае, код не может получить более широкие или ограниченные разрешения, чем это
предписано политикой безопасности. Разрешение предоставляется только раз и
определяет права всего кода в сборке. Для просмотра и изменения политики
безопасности используется инструмент настройки .NET Framework (Mscorcfg.msc).

Mscorcfg.msc

Планируем боевые действия

Есть такая японская пословица: «Выходи из дома так, как будто он окружен
тысячей врагов». Понятно, что во времена феодальной Японии, когда туда-сюда
бегали самураи, воевали между собой и искали других приключений, это пословица
была актуальной. Сегодня, позволю себе заметить, эта пословица будет
справедливой и для твоего кода — если ты думаешь, что твой код никому нафиг не
сдался, ты глубоко ошибаешься.

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

Ihre ausweiss, bitte!: выдача разрешений

Защита на основе признаков базируется на предположении, что высокий уровень
доверия (с широкими полномочиями) присваивается лишь коду, заслуживающему этого
самого доверия, а злонамеренный код является «малодоверяемым» или вообще не
имеет разрешений. В соответствии с политикой по умолчанию в .NET Framework
разрешения выдаются на основе зон (так, как они определены в Microsoft Internet
Explorer). Ниже приведено упрощенное описание этой политики «по умолчанию»:

• Зона локального компьютера (например, C:app.exe) является
  полностью доверяемой. Предполагается, что пользователи помещают на свой
  компьютер только код, которому они доверяют, и что большинство пользователей
  не собираются разбивать свой жесткий диск на области с разной степенью
  доверия. По существу, этот код может делать все что угодно, поэтому от
  злонамеренного кода, находящегося в этой зоне, никакой защиты нет. Честно
  говоря, по моему скромному мнению, именно это предположение является одной
  из огромных дыр в архитектуре безопасности Windows, что приводит к появлению
  таких извратов, как UAC, DEP, рандомизация стека, сандбоксов и пр.
• Зона интернета (например, http://www.microsoft.com). Коду из этой
  зоны предоставляется очень ограниченный набор разрешений, который не опасно
  предоставить даже злонамеренному коду. Обычно этому коду нельзя доверять,
  поэтому его можно безопасно выполнять только с очень узкими разрешениями, с
  которыми он не сумеет нанести ущерб:
• WebPermission — доступ к серверу сайта, с которого получен код;
• FileDialogPermission — доступ только к файлам, специально
  указанным пользователем;
• IsolatedStorageFilePermission — постоянное хранилище,
  ограниченное пределами веб-сайта;
• UlPermission — возможность записи информации в окно
  пользовательского интерфейса;
• Зона интрасети (например \UNCshare). Код из этой зоны
  выполняется с чуть большими разрешениями, чем код из интернета, но среди них
  все равно нет таких, которые предоставляли бы широкие полномочия;
• FilelOPermission — доступ только для чтения к файлам каталога, из
  которого загружен код;
• DNSPermission — допускается разрешение DNS-имен в IP-адреса;
• FileDialogPermission — доступ только к файлам, специально
  указанным пользователем;
• Isolated StorageFilePermission — постоянное хранилище (с меньшими
  ограничениями);

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

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

Не влезай — убьет!

Какие разрешения несут в себе потенциальную опасность? Для выполнения
некоторых защищенных операций .NET Framework предоставляет разрешения,
потенциально позволяющие обойти систему защиты. Эти опасные разрешения следует
предоставлять только коду, заслуживающему доверия, и только при абсолютной
необходимости. Обычно, если злонамеренный код получает такие разрешения, то
защититься нельзя. К опасным разрешениям относятся:

• Unmanaged Code — позволяет управляемому коду вызывать неуправляемый код,
  что зачастую весьма опасно;
• Skip Verification — код может делать что угодно без всякой верификации;
• ControlEvidence — управление признаками позволяет обмануть систему
  защиты;
• ControlPolicy — возможность изменять политику безопасности позволяет
  отключить защиту;
• SerializationFormatter — за счет сериализации можно обойти управление
  доступом;
• ControlPrincipal — возможность указывать текущего пользователя позволяет
  обходить защиту на основе ролей;
• ControlThread — возможность манипуляций с потоками опасна, так как с
  ними связано состояние защиты;

• MemberAccess — позволяет отключать механизм управления доступом
  (становится возможным использование закрытых членов).

Защита доступа к методам

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

Утилита графической настройки прав доступа к коду GuiCaspol

Иногда приходится ограничивать доступ к методам, которые не предназначены для
открытого использования, но все равно должны быть объявлены как открытые.
Например, у тебя есть некий интерфейс, вызываемый вашими же DLL, и поэтому он
должен быть открытым, но ты не хочешь, чтобы этот интерфейс был общедоступным,
так как нежелательно, чтобы клиенты могли с ним работать, или чтобы
злонамеренный код воспользовался им как точкой входа в твой компонент. Еще одна
типичная причина ограничения доступа к методу, который не предназначен для
общего использования (но, тем не менее, должен быть открытым) — стремление
избежать документирования и поддержки интерфейса, применяемого исключительно на
внутреннем уровне. Поэтому вот тебе несколько советов, как можно ограничить
доступ к методам в управляемом коде:

• Ограничь область доступности классом, сборкой или производными классами
  (если им можно доверять). Это простейший способ ограничения доступа к
  методу. Замечу, что вообще-то производные классы могут быть менее
  доверяемыми, чем класс-предок, но в некоторых случаях они используют ту же
  идентификацию, что и надкласс. В частности, ключевое слово protected не
  подразумевает доверия, и его необязательно нужно использовать в контексте
  защиты;
• Разрешай вызов метода только вызывающим с определенной идентификацией
  (обладающим заданными вами признаками);
• Разрешай вызов метода только тем, у кого есть требуемые разрешения.

Аналогичным образом декларативная защита позволяет контролировать
наследование классов. С помощью InheritanceDemand можно потребовать наличия
определенной идентификации или разрешения от:

• Всех производных классов;
• Производных классов, переопределяющих те или иные методы.

Защищаем доступ к методу или классу

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

1. Команда sn -k создает пару из закрытого и открытого ключа. Закрытая часть
нужна, чтобы подписать код строгим именем (strong name), и хранится в безопасном
месте издателем кода. Если она станет известной, указать твою подпись в своем
коде сможет кто угодно.

sn -k keypair.dat
csc/r:App1.dll /a. keyfile: keypair.dat App1.cs
sn -p keypair.dat public.dat
sn -tp public.dat >publichex.txt
[StrongNameldentityPermissionAttribute ( SecurityAction . LinkDemand , PublicKey=». hex. «,Name=»App1»,
Version=»0. 0.0.0″)]
public class MyClass

2. Команда esc компилирует и подписывает Appl, предоставляя ему доступ к
защищенному методу.

3. Следующие две команды sn извлекают из пары открытый ключ и преобразуют его
в шестнадцатеричную форму.

4. Во второй половине показанного исходного кода содержится фрагмент
защищаемого метода. Пользовательский атрибут (custom attribute) определяет
строгое имя и в шестнадцатеричном формате вставляет открытый ключ, полученный
командой sn, в атрибут PublicKey.

5. В период выполнения Appl имеет необходимую подпись со строгим именем и
может использовать MyClass. В этом примере для защиты API-элемента применяется
атрибут LinkDemand.

В примере, показанном ниже, частично доверенному коду запрещается обращаться
к классам и методам (а также к свойствам и событиям). Когда такие объявления
применяются к классу, защищаются все методы, свойства и события этого класса.
Однако декларативная защита не влияет на доступ к полям. Кроме того, учти, что
требования к связи (link demands) защищают только от непосредственно вызывающего
кода — возможность атак с подменой сохраняется.

[System.Security.Permissions. PermissionSetAttribute(System.Security.
Permissions.SecurityAction.InheritanceDemand, Name=»FullTrust»)]
[System.Security.Permissions. PermissionSetAttribute(System.Security.
Permissions.SecurityAction.LinkDemand, Name=»FullTrust»)]
public class YourClass

Утилита ручной настройки прав доступа к коду

Приемы безопасного кодинга

Запрос разрешений — отличный способ обеспечить поддержку защиты в
разрабатываемом коде. Он позволяет запрашивать минимальные разрешения,
необходимые для выполнения кода, и гарантировать, что код не получит разрешений
больше, чем нужно. Например:

[assemblyiFilelOPermissionAttribute (SecurityAction.RequestMinimum,
Wrlte=»C:\test.tmp»)]
[assembly:РеrmissionSet(SecurityAction.RequestOptional. Unrestricted=false)]
. SecurityAction.RequestRefused .

В этом примере системе сообщается, что код не должен запускаться, пока не
получит разрешение на запись в C:test.tmp. Если одна из политик безопасности не
предоставляет такое разрешение, генерируется исключение PolicyException, и код
не запускается. Ты должен убедиться в том, что коду выдается нужное разрешение,
и тогда тебе не придется беспокоиться об ошибках из-за нехватки разрешений.
Кроме того, здесь система уведомляется о том, что дополнительные разрешения
нежелательны. Иначе код получит все разрешения, предусмотренные политикой
безопасности. Лишние разрешения не принесут вреда, но, если в системе
безопасности есть какая-то ошибка, уменьшение числа разрешений, выдаваемых коду,
может прикрыть брешь в защите. Таким образом, если код обладает разрешениями,
которые ему не нужны, возможны проблемы с безопасностью. Еще один способ
ограничить количество привилегий, предоставляемых коду — явно перечислить
разрешения, от которых следует отказаться. Отказ от разрешений осуществляется
объявлением необязательности разрешений и исключением конкретных разрешений из
запроса.

Заключение

Уфф! На тему обеспечения безопасности твоего кода можно говорить бесконечно.
В рамках этой статьи я постарался упомянуть только самое важное и, на мой
взгляд, интересное. Иными словами, то, что должно помочь тебе сделать свои
приложения непробиваемыми. В общем, да пребудет с тобой Сила!

Источник: xakep.ru