что такое безопасный код

Несколько мыслей по поводу безопасного кода

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

Очень часто программисты проникаются мыслями о пользователе, когда они работают в визуальных средах. Такие среды как Delphi или Visual Studio позволяют легко определить обработку событий элементов управления, с которыми работает пользователь. Легко поддаться соблазну и дважды нажав в редакторе формы на кнопке задать действие, которое определило бы обработку действия пользователя. Формально – это правильно. Но рассмотрим пример:

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

Контекста нет, есть только требования безопасности

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

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

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

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

Что это значит? Все просто: забудьте про контекст, следуйте правилам безопасности.

Код всегда вызывается «злым» кодом

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

Итак переделаем предыдущий пример так, как он того заслуживает:

Исключительные ситуации заслуживают исключительных мер

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

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

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

Все ответы – отрицательные

enum Access
<
Granted,
Restricted
>
private Access CheckLogin( string password)
<
Access result = Access.Granted;

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

Для возврата результата я определил несколько правил:
• в незначительных методах, которые не будут вызывать исключения при проблемах, избегайте возвращать не nullable типы, кроме булевых значений;
• все методы, возвращающие значения, первым делом должны инициализировать это значение самым отрицательным или безопасным вариантом (для nullable типов – это может быть null, для булевых – false, для перечислений – самое негативное значение вроде Access.Restricted);
• все методы должны иметь одну точку для возврата значений.
В результате можно выделить такой паттерн:

private Access MyMethod()
<
Access result = Access.Restricted;

// помещайте свой код здесь, в коде не должно быть вызовов return, только изменение значения result

Источник

Безопасный код: Работа с пользовательским вводом

(ч2. Подделка межсайтовых запросов; ч2. Работа с базой данных)

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

Некоторые сценарии XSS атак

Устойчивая атака

Неустойчивая атака

Как обезопасить код от XSS?

Ответ прост — фильтровать вывод на страницу.

Методы фильтрации в Друпале

Золотое правило работы с данными — хранить пользовательский ввод в базе именно в том виде, в котором он был отправлен. Поэтому, всю фильтрацию следует производить на этапе вывода пользовательских данных на страницу.

Весь пользовательский ввод можно разделить на два типа:

Текст без разметки (plain text)

Любой пользовательский ввод, который должен быть подан в виде чистого текста, должен проходить через функцию check_plain(), которая превратит кавычки, амперсанды и угловые скобки в их HTML представление. Затем, такой текст может быть уже вставлен в конечную HTML разметку страницы.

$form[‘good’] = array(
‘#type’ => ‘checkboxes’,
‘#options’ => array(check_plain($u_supplied0), check_plain($u_supplied1)),
);

Текст с разметкой

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

-=Бонус=-

Видео-доклад «Introduction Security» с прошедшего друпалкона:

Источник

Чистый и безопасный код — миф или реальность?

«Программирование — это искусство сообщать другому человеку, что он хочет от компьютера»

Каждый язык программирования разработан с учетом разных операционных систем, платформ, стилей кодирования и предполагаемого использования. Обычно мы слышим о языках Python, PHP, Ruby, JavaScript, Java, C, C++ и C#, а также более современных их разновидностях, такие как Rust, Swift, Hack и многих других.

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

Когда речь заходит о чистом коде, мы представляем идеально продуманные строки. Это код, который был спланирован до того, как был написан. Настолько хорошо спланирован, что при первом запуске он работает без ошибок и без изъянов.

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

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

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

Небрежно написанный код стоит дорого, а на его обслуживание уходит много времени и усилий. Кроме того, код более подвержен ошибкам, которые могут привести к сбою программы.

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

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

Отладка — это исправление ошибок в коде.

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

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

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

Код должен соответствовать правилу DRY (Don’t repeat yourself с англ. — «не повторяйтесь»). Это означает, что любое изменение в одном участке не должно требовать изменений в других.

Если в коде существует множество зависимостей, его сложнее поддерживать или изменять в будущем.

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

Код должен быть прост, удобен и понятен, чтобы любой разработчик мог его быстро прочитать. Для этого многие разработчики используют правила KISS (keep it simple and straightforward с англ. — «сохраняйте простоту») и YAGNI (You aren’t gonna need it с англ. — «вам это не понадобится»).

Используйте языковые инструменты статического анализа для проверки вашего кода.

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

Согласно отчету Veracode, более трех четвертей (75,8%) приложений имеют хотя бы один недостаток безопасности, а 23,7% содержат недостатки высокой степени серьезности, и исправление этих недостатков обычно занимает месяцы.

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

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

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

Список существующих уязвимостей довольно длинный, поэтому мы рассмотрим лишь некоторые из часто встречающихся, а также те, которые причиняют наибольший ущерб. Согласно исследованию одними из наиболее популярных уязвимостей являются: Information leakage (утечка информации) — 65,9%; Cross-Site Scripting (XSS, межсайтовый скриптинг) — 47,1%; SQL Injection (внедрение SQL-кода) — 27,8%.

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

В идеальном мире разработчик (самостоятельно или с привлечением специалистов) тестирует продукт на проникновение, применяя наиболее популярные и новые методы взлома, а после анализирует полученный результат и делает выводы.

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

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

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

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

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

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

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

Это высоко ценимая книга в индустрии разработки ПО. Основной посыл — «ошибки в программном обеспечении возникают из-за сложности кода». Книга была написана почти 30 лет назад, с тех пор идеи прочно вошли в сообщество разработчиков программного обеспечения.

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

Одним из недостатков является большой объем книги и то, что она, похоже, в основном ориентирована на объектно-ориентированные языки (C ++, Java) и даже более старые императивные (C, Ada и т. Д.)

Hack The Box — это онлайн-платформа для обучения кибербезопасности, позволяющая проверить свои навыки тестирования на проникновение. Платформа предоставляет множество задач. Некоторые из них моделируют сценарии реального мира, а некоторые больше похожи на задачи CTF. Hack The Box постоянно предлагает свежие хакерские задачи в полностью игровой и интуитивно понятной среде.

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

Курс «Веб-безопасность» содержит обзор самых распространенных атак, ключевых мер защиты веб-приложений (корпоративных порталов, ДБО, систем электронной коммерции и т.д.) и методов аудита кода. С курсом «Безопасное программирование на Java» вы сможете развить навыки защиты, выполняя задания на эксплуатацию и исправление кода в приложениях, написанных на Java. При этом результаты будут видны сразу на живом приложении.

На платформе Pentestit есть программы практического обучения в области информационной безопасности: Zero Security: A и Corporate Laboratories. Учебный процесс включает теоретические и практические занятия, на которых опытные инструкторы Pentestit рассказывают о характере и способах обнаружения уязвимостей.

«Zero Security: A» — это программа начального обучения тестированию на проникновение Pentestit, в рамках которой стажеры осваивают различные инструменты тестирования на проникновение и изучают основы этического взлома: от разведки и сбора информации до обеспечения безопасности в системе.

Хороший (и бесплатный) ресурс, хотя сосредоточенный на веб-приложениях, а не на тестировании на проникновение в целом. Он включает в себя материалы собственной исследовательской группы PortSwigger и лабораторные работы, где вы можете проверить полученные знания.

Одна из самых известных и популярных образовательных платформ. На сегодняшний день у них есть учебники по HTML, CSS, Sass, JavaScript, Rails, AngularJS, ReactJS, Ruby, Command Line, Git, SQL и Java.

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

Миф. Следующий вопрос.

В определенный момент осваиваешь каждый раз всё новое и необходимое для развития. Это утечки, загрузка, многопоточность, умение написать полет снаряда с учетом законов физики (когда движок ничего не дает, разве что синус рассчитать может).

Потом была пауза. Армия. Вернулся, думал я сис админ.
В итоге, в свободное время стал писать игры в браузере для себя.
Позже занялся рекламой, так как всё так же сис-админил.

И только в 2017 году обнаружил, что все эти навыки ценны. Но я всё это делал для себя) Так что, кто то занимается для себя, а кто то ради другой цели, поэтому и есть всегда эта проблема «а почему код грязный?».

Источник

СОДЕРЖАНИЕ

Предотвращение переполнения буфера

Пример программы C, склонной к переполнению буфера:

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

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

Предотвращение атак с форматной строкой

Функция C printf записывает вывод в stdout. Если параметр функции printf не отформатирован должным образом, может появиться несколько ошибок безопасности. Ниже представлена ​​программа, уязвимая для атаки на строку формата.

Вредоносный аргумент, переданный программе, может быть «% s% s% s% s% s% s% s», что может привести к сбою программы из-за неправильного чтения памяти.

Предотвращение целочисленного переполнения

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

Ниже приведена функция на C ++, которая пытается подтвердить, что сумма x и y меньше или равна определенному значению MAX:

Ниже приведена функция, которая проверяет переполнение, подтверждая, что сумма больше или равна как x, так и y. Если бы сумма переполнилась, сумма была бы меньше x или меньше y.

Предотвращение обхода пути

Источник

Безопасность доступа кода

На этом уровне проводится различие между кодом, которому разрешено выполнять привилегированные вызовы (такие как вызовы собственного кода), и кодом, которому это делать не разрешается. Весь код делится на три категории:

Критичный для безопасности код (Security-Critical Code)

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

Безопасный код (Safe-Critical Code)

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

Прозрачный код

В рамках этого кода может выполняться очень ограниченное число операций. Этому коду разрешено выполняться только с определенным набором разрешений и только в песочнице (sandbox). В нем не может содержаться никакого небезопасного или непроверяемого кода и вызываться критичный для безопасности код. При написании Windows-приложений ограничение прав кода не применяется.

Приложения, выполняющиеся в настольной среде, обладают всеми привилегиями доверия и могут содержать любой код. Технология изоляции кода на время выполнения в называемую песочницей (sandbox) ограниченную среду применяется с приложениями SilverLight, а также приложениями ASP.NET, которые обслуживаются веб-провайдером или обладают специфической функциональностью, например, предусматривают запуск дополнительных надстроек за счет использования Managed Add-In Framework.

Второй уровень прозрачной безопасности

В случае применения атрибута SecurityTransparent вся сборка не будет делать ничего привилегированного или небезопасного. Она сможет только вызывать какой-то прозрачный или безопасный код. Применять этот атрибут допускается только на уровне всей сборки.

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

Если не применен ни один из этих атрибутов, код считается критическим для безопасности. Однако при желании в нем можно применить атрибут SecuritySafeCritical к отдельным типам и членам и тем самым сделать их пригодными для вызова из прозрачного кода:

Полномочия

Под полномочиями, или разрешениями, понимаются действия, которые разрешается (или запрещается) выполнять каждой группе кода. Например, полномочия могут включать в себя «чтение файлов из файловой системы», «выполнение операций записи в Active Directory» и «использование сокетов для открытия сетевых соединений». Есть несколько предопределенных полномочий, и можно также создавать собственные.

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

DirectoryServicesPermission

Позволяет управлять возможностью получать доступ к Active Directory с помощью классов System.DirectoryServices.

DnsPermission

Позволяет управлять возможностью использования DNS (Domain Name System — служба имен доменов).

EnvironmentPermission

Позволяет управлять возможностью выполнять чтение и запись в переменных среды.

EventLogPermission

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

FileDialogPemission

Позволяет управлять возможностью получать доступ к файлам, которые пользователь выбирает в диалоговом окне Open (Открыть). Обычно такое полномочие применяется в случае невыдачи полномочия FileIOPermission для предоставления хотя бы ограниченного доступа к файлам.

FileIOPermission

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

IsolatedStorageFilePermission

Позволяет управлять возможностью доступа к приватным виртуальным файловым системам.

IsolatedStoragePermission

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

MessageQueuePermission

Позволяет управлять возможностью использования очереди сообщений через службу Microsoft Message Queue.

PerformanceCounterPermission

Позволяет управлять возможностью использования счетчиков производительности.

PrintingPermission

Позволяет управлять возможностью выполнения печати.

ReflectionPermission

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

RegistryPermission

Позволяет управлять возможностью чтения, записи, создания и удаления разделов и параметров в системном реестре.

SecurityPermission

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

ServiceControllerPermission

Позволяет управлять возможностью осуществлять управление службами Windows.

Socket Permission

Позволяет управлять возможностью создания или приема соединений TCP/IP по сетевому транспортному адресу.

SQLClientPermission

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

Наборы полномочий

Под наборами полномочий понимаются коллекции разрешений. Они избавляют от необходимости применять к коду каждое разрешение отдельно и позволяют группировать необходимые разрешения и применять их к коду сразу вместе. Например, сборка с набором полномочий FullTrust будет иметь полный доступ ко всем ресурсам, а сборка с набором полномочий Local Intranet — лишь ограниченный с возможностью выполнения операций записи только в изолированном хранилище и больше нигде в файловой системе. Допускается создавать собственные наборы полномочий, включающие только определенные разрешения.

Важно обратить внимание на то, что изменять определения полномочий можно только в наборе Everything (Все); остальные наборы являются фиксированными и изменяться не могут. Разумеется, можно создавать и собственные наборы полномочий.

Запрос полномочий программным образом

Сборка может запрашивать полномочия как декларативным, так и программным образом. В следующем фрагменте кода показано, как запрашивать полномочия с помощью метода DemandFileIOPermissions(). После импорта пространства имен System.Security.Permisions можно выполнять проверку на предмет наличия необходимых полномочий, создавая объект FileIOPermission и вызывая его метод Demand().

Этот метод позволяет проверить, есть ли у кода, вызывающего метод, в данном случае — DemandFileIOPermissions, необходимые полномочия. Если метод Demand() завершается неудачей, генерируется исключение типа SecurityException. Это исключение можно не перехватывать, и предоставлять его обработку вызывающему коду.

Класс FileIOPermission содержится внутри пространства имен System.Security.Permisions, в котором определен полный набор полномочий, а также классы для декларативных атрибутов полномочий и перечисления для параметров, применяемых для создания объектов полномочий (например, создания объекта FileIOPermission, указывающего, требуется доступ только для чтения или же полный доступ).

Для перехвата исключений, генерируемых исполняющей средой CLR, когда код пытается выполнить какие-то противоречащие выданным ему полномочиям действия, можно организовать перехват исключения типа SecurityException. Это исключение предоставляет доступ к набору полезных фрагментов информации, в том числе читабельной трассировке стека (SecurityException.StackTrace) и ссылке на метод, который привел к выдаче исключения (SecurityException.TargetSite). Вдобавок SecurityException предоставляет свойство SecurityException.PermissionType, которое возвращает информацию о типе объекта Permission, вызвавшего генерацию исключения.

Источник