Рекомендации по написанию безопасного кода
Обновлен: Ноябрь 2007
Ниже представлен ряд рекомендаций и способов написания безопасного кода.
Обязательные действия
Использовать средства анализа кода.
Visual Studio Team System Development Edition имеет встроенные средства анализа кода, позволяющие существенно повысить вероятность обнаружения в коде ошибок безопасности. Данные средства выявляют ошибки с большей эффективностью, требуя для этого меньше усилий. Дополнительные сведения см. в разделах Выявление и исправление дефектов кода C/C++ и Выявление и исправление дефектов управляемого кода.
Проводить проверку безопасности.
Цель каждой проверки безопасности заключается либо в повышении безопасности уже выпущенных продуктов — путем поставки исправлений — либо в обеспечении максимальной безопасности новых продуктов перед их выпуском.
Не проводите беспорядочных проверок кода. Подготовьтесь заранее к проверке безопасности и начните с тщательной разработки модели угрозы. Если этого не сделать, значительная часть времени группы может быть потрачена впустую. Уделите первостепенное внимание коду, который требует наиболее серьезной проверки безопасности, и определите ошибки безопасности, на которые следует ориентироваться.
Конкретизируйте, что именно нужно найти в ходе проверки безопасности. Поиск конкретных ошибок, как правило, дает нужные результаты. Приложите дополнительные усилия при поиске, если группа выявила много ошибок безопасности в одной и той же области; это может указывать на проблему архитектурного плана, которая требует исправления. Если не найдено ни одной ошибки безопасности, как правило, это означает, что проверка безопасности проведена неверно.
Проводите проверку безопасности в рамках стабилизации каждого этапа наряду с более крупной проверкой на уровне всего семейства продуктов, организуемой руководством.
Использовать контрольный список проверки безопасности кода.
Независимо от роли в группе разработки всегда рекомендуется использовать контрольный список, который позволит удостовериться в том, что проект и код отвечают минимальным требованиям.
Проверять все вводимые пользователями данные.
Если приложение использует введенные пользователями данные прямым или косвенным образом, такие данные необходимо проверить перед их использованием. Злоумышленники могут попытаться вывести приложение из строя путем ввода недействительных данных. Первое правило для обработки вводимых пользователями данных гласит, что все введенные данные неверны до тех пор, пока не доказано обратное.
Соблюдайте осторожность при использовании регулярных выражений для проверки введенных пользователями данных. В случае со сложными выражениями, такими как адрес электронной почты, может создаться впечатление, что проводится полная проверка, хотя на самом деле это не так. Отдавайте все регулярные выражения на проверку партнерам.
Проводить серьезную проверку всех параметров экспортированных интерфейсов прикладного программирования (API).
Удостоверьтесь в том, что все параметры экспортированных интерфейсов прикладного программирования действительны. Сюда относится ввод данных, которые имеют согласованный вид, но выходят за рамки принятого диапазона значений, например слишком большие размеры буфера. Не используйте утверждений для проверки параметров экспортированных интерфейсов прикладного программирования, потому как утверждения будут удалены при построении выпуска.
Использовать API-интерфейсы шифрования Windows.
Вместо написания собственного шифровального программного обеспечения используйте уже имеющийся API-интерфейс шифрования Microsoft. Использование разработанного корпорацией Майкрософт API-интерфейса шифрования позволяет разработчикам сконцентрироваться на построении приложений. Помните, что шифрование очень хорошо решает ограниченный ряд проблем и зачастую используется в целях, для которых оно не предназначено. Дополнительные сведения см. в разделе Общие сведения о криптографии библиотеки MSDN.
Нерекомендуемые действия
Вызывать переполнение буфера.
Статическое переполнение буфера происходит, когда в заявленный в стеке буфер копируются данные, превышающие его по объему. Заявленные в стеке переменные расположены рядом с обратным адресом вызывающего объекта функции. Переполнение буфера также может произойти в куче, что не менее опасно. Как правило, виновником переполнения буфера являются непроверенные введенные пользователем данные, переданные в такую функцию, как strcpy, в результате чего обратный адрес функции заменяется адресом, выбранным злоумышленником. Предотвращение переполнений буфера по большей части зависит от степени надежности приложения.
Использование утверждений для проверки внешних данных.
Утверждения не компилируются в коммерческие построения. Не используйте утверждения для проверки данных, поступивших извне. Все параметры экспортированных функций и методов, все введенные пользователями данные, а также все файловые и сокетные данные должны проходить тщательную проверку на достоверность, а в случае непригодности отклоняться.
Использовать жестко закодированные пары из идентификатора пользователя и пароля.
Не используйте жестко закодированные пароли. Измените установщик таким образом, чтобы при создании встроенных учетных записей пользователей администратору предлагалось задать надежные пароли для каждой учетной записи. Таким образом можно обеспечить безопасность производственных систем заказчика.
Использовать шифрование для решения всех проблем безопасности.
Шифрование очень хорошо решает ограниченный ряд проблем и зачастую используется в целях, для которых оно не предназначено.
Использовать канонические пути файлов и URL-адресов.
Избегайте ситуаций, когда расположение файла или URL-адрес играют важную роль. Используйте списки ACL файловой системы вместо правил, основанных на канонических именах файлов.
Рекомендуемые действия
Просматривать все прошлые ошибки безопасности, допущенные в приложении.
Ознакомьтесь с ошибками безопасности, которые были допущены в прошлом. Зачастую код пишется по привычному шаблону. Поэтому ошибка, допущенная одним разработчиком в одном месте, может означать, что такая же ошибка допущена в других местах другими разработчиками.
Проверять все пути ошибок.
Зачастую код в путях ошибок не проходит тщательного тестирования и не обеспечивает очистки всех объектов, таких как блокировки или выделенная память. Тщательно проверьте данные пути и при необходимости проведите тестирование с внесением неисправностей для испытания кода.
Нерекомендуемые действия
Использовать права администратора для работы приложения.
Приложения должны работать с минимальными правами, требуемыми для выполнения задач. Если злоумышленник найдет уязвимость в системе безопасности и внедрит в процесс свой код, вредоносный код будет иметь такие же права, как и главный процесс. Если процесс имеет права администратора, вредоносный код будет также иметь права администратора. Дополнительные сведения см. в разделе Разработка безопасных приложений в библиотеке MSDN.