Рекомендации по написанию безопасного кода
Ниже представлен ряд рекомендаций и способов написания безопасного кода.
Требуется
Использовать средства анализа кода.
Visual Studio Premium включает встроенные средства анализа кода, позволяющие существенно повысить вероятность обнаружения в коде ошибок безопасности. Данные средства выявляют ошибки с большей эффективностью, требуя для этого меньше усилий. Дополнительные сведения см. в одном из следующих разделов.
Проводить проверку безопасности.
Цель каждой проверки безопасности заключается либо в повышении безопасности уже выпущенных продуктов — путем обновлений — либо в обеспечении максимальной безопасности новых продуктов перед их выпуском.
Не проводите беспорядочных проверок кода. Подготовьтесь заранее к проверке безопасности и начните с тщательной разработки модели угрозы. Если этого не сделать, значительная часть времени группы может быть потрачена впустую. Уделите первостепенное внимание коду, который требует наиболее серьезной проверки безопасности, и определите ошибки безопасности, на которые следует ориентироваться.
Конкретизируйте, что именно нужно найти в ходе проверки безопасности. Поиск конкретных ошибок, как правило, дает нужные результаты. Следует анализировать еще тщательнее, если ваша команда находит много ошибок безопасности в определенной области. Возможно, это указывает на архитектурную ошибку, которую необходимо исправить. Если не найдено ни одной ошибки безопасности, как правило, это означает, что проверка безопасности проведена неверно.
Проводите проверку безопасности в рамках стабилизации каждого этапа наряду с более крупной проверкой на уровне всего семейства продуктов, организуемой руководством.
Использовать контрольный список проверки безопасности кода.
Независимо от роли в группе разработки всегда рекомендуется использовать контрольный список, который позволит удостовериться в том, что проект и код отвечают минимальным требованиям.
Проверять все вводимые пользователями данные.
Если приложение использует введенные пользователями данные прямым или косвенным образом, такие данные необходимо проверить перед их использованием. Злоумышленники могут попытаться вывести приложение из строя путем ввода недействительных данных. Первое правило для обработки вводимых пользователями данных гласит, что все введенные данные неверны до тех пор, пока не доказано обратное.
Соблюдайте осторожность при использовании регулярных выражений для проверки введенных пользователями данных. В случае со сложными выражениями, такими как адрес электронной почты, может создаться впечатление, что проводится полная проверка, хотя на самом деле это не так. Отдавайте все регулярные выражения на проверку партнерам.
Проводите серьезную проверку всех параметров экспортированных и открытых программных интерфейсов (API).
Удостоверьтесь в том, что все параметры экспортированных и открытых программных интерфейсов действительны. Сюда относится ввод данных, которые имеют согласованный вид, но выходят за рамки принятого диапазона значений, например большие размеры буфера. Не используйте утверждений для проверки параметров экспортированных интерфейсов прикладного программирования, потому как утверждения будут удалены при построении выпуска.
Использовать API-интерфейсы шифрования Windows.
Вместо написания собственного шифровального программного обеспечения используйте уже имеющийся API-интерфейс шифрования Microsoft. Использование разработанного корпорацией Майкрософт API-интерфейса шифрования позволяет разработчикам сконцентрироваться на построении приложений. Помните, что шифрование очень хорошо решает ограниченный ряд проблем и зачастую используется в целях, для которых оно не предназначено. Для получения дополнительной информации см. раздел Cryptography Reference в библиотеке MSDN.
Нерекомендуемые действия
Вызывать переполнение буфера.
Статическое переполнение буфера происходит, когда в заявленный в стеке буфер копируются данные, превышающие его по объему. Заявленные в стеке переменные расположены рядом с обратным адресом вызывающего объекта функции. Переполнение буфера также может произойти в куче, что не менее опасно. Как правило, виновником переполнения буфера являются непроверенные введенные пользователем данные, переданные в такую функцию, как strcpy, в результате чего обратный адрес функции заменяется адресом, выбранным злоумышленником. Предотвращение переполнений буфера по большей части зависит от степени надежности приложения.
Использование утверждений для проверки внешних данных.
Утверждения не компилируются в коммерческие построения. Не используйте утверждения для проверки данных, поступивших извне. Все параметры экспортированных функций и методов, все введенные пользователями данные, а также все файловые и сокетные данные должны проходить тщательную проверку на достоверность, а в случае непригодности отклоняться.
Использовать жестко закодированные пары из идентификатора пользователя и пароля.
Не используйте жестко закодированные пароли. Измените установщик таким образом, чтобы при создании встроенных учетных записей пользователей администратору предлагалось задать надежные пароли для каждой учетной записи. Таким образом можно обеспечить безопасность производственных систем заказчика.
Использование шифрования для решения всех проблем безопасности.
Шифрование очень хорошо решает ограниченный ряд проблем и зачастую используется в целях, для которых оно не предназначено.
Использовать канонические пути файлов и URL-адресов.
Избегайте ситуаций, когда расположение файла или URL-адрес играют важную роль. Используйте списки ACL файловой системы вместо правил, основанных на канонических именах файлов.
Рекомендовано
Просматривать все прошлые ошибки безопасности, допущенные в приложении.
Ознакомьтесь с ошибками безопасности, которые были допущены в прошлом. Зачастую код пишется по привычному шаблону. Поэтому ошибка, допущенная одним разработчиком в одном месте, может означать, что такая же ошибка допущена в других местах другими разработчиками.
Проверять все пути ошибок.
Зачастую код в путях ошибок не проходит тщательного тестирования и не обеспечивает очистки всех объектов, таких как блокировки или выделенная память. Тщательно проверьте данные пути и при необходимости проведите тестирование с внесением неисправностей для испытания кода. Для получения дополнительной информации см. раздел Input Validation в теме Design Guidelines for Secure Web Applications и раздел Input Validation в теме Architecture and Design Review for Security в библиотеке MSDN.
Нежелательные действия
Использовать права администратора для работы приложения.
Приложения должны работать с минимальными правами, требуемыми для выполнения задач. Если злоумышленник найдет уязвимость в системе безопасности и внедрит в процесс свой код, вредоносный код будет иметь такие же права, как и главный процесс. Если процесс имеет права администратора, вредоносный код будет также иметь права администратора. Дополнительные сведения см. в документе Developing Software in Visual Studio .NET with Non-Administrative Privileges в библиотеке MSDN.