19 смертных грехов, угрожающих безопасности программ
Шрифт:
Не рекомендуется
□ Не думайте, что компилятор и ОС все сделают за вас, это всего лишь дополнительные средства защиты.
□ Не используйте небезопасные функции в новых программах.
Стоит подумать
□ Об установке последней версии компилятора C/C++, поскольку разработчики включают в генерируемый код новые механизмы защиты.
□ О постепенном удалении небезопасных функций
□ Об использовании строк и контейнерных классов из библиотеки С++ вместо применения низкоуровневых функций С для работы со строками.
Грех 2.
Ошибки, связанные с форматной строкой
Рекомендуется
□ Пользуйтесь фиксированными форматными строками или считываемыми из заслуживающего доверия источника.
□ Проверяйте корректность всех запросов к локали.
Не рекомендуется
□ Не передавайте поступающие от пользователя форматные строки напрямую функциям форматирования.
Стоит подумать
□ О том, чтобы использовать языки высокого уровня, которые в меньшей степени уязвимы относительно этой ошибки.
Грех 3.
Переполнение целых чисел
Рекомендуется
□ Проверяйте на возможность переполнения все арифметические вычисления, в результате которых определяется размер выделяемой памяти.
□ Проверяйте на возможность переполнения все арифметические вычисления, в результате которых определяются индексы массивов.
□ Пользуйтесь целыми без знака для хранения смещений от начала массива и размеров блоков выделяемой памяти.
Не рекомендуется
□ Не думайте, что ни в каких языках, кроме C/C++, переполнение целого невозможно.
Грех 4.
Внедрение SQL–команд
Рекомендуется
□ Изучите базу данных, с которой работаете. Поддерживаются ли в ней хранимые процедуры? Как выглядит комментарий? Может ли противник получить доступ к расширенной функциональности?
□ Проверяйте корректность входных данных и устанавливайте степень доверия к ним.
□ Используйте параметризованные запросы (также распространены термины «подготовленное предложение» и «связывание параметров») для построения SQL–предложений.
□ Храните информацию о параметрах соединения вне приложения, например в защищенном конфигурационном файле или в реестре Windows.
Не рекомендуется
□ Не ограничивайтесь простой фильтрацией «плохих слов». Существует множество вариантов написания, которые
□ Не доверяйте входным данным при построении SQL–предложения.
□ Не используйте конкатенацию строк для построения SQL–предложения даже при вызове хранимых процедур. Хранимые процедуры, конечно, полезны, но решить проблему полностью они не могут.
□ Не используйте конкатенацию строк для построения SQL–предложения внутри хранимых процедур.
□ Не передавайте хранимым процедурам непроверенные параметры.
□ Не ограничивайтесь простым дублированием символов одинарной и двойной кавычки.
□ Не соединяйтесь с базой данных от имени привилегированного пользователя, например sa или root.
□ Не включайте в текст программы имя и пароль пользователя, а также строку соединения.
□ Не сохраняйте конфигурационный файл с параметрами соединения в корне Web–сервера.
Стоит подумать
□ О том, чтобы запретить доступ ко всем пользовательским таблицам в базе данных, разрешив лишь исполнение хранимых процедур. После этого во всех запросах должны использоваться только хранимые процедуры и параметризованные предложения.
Грех 5.
Внедрение команд
Рекомендуется
□ Проверяйте все входные данные до передачи их командному процессору.
□ Если проверка не проходит, обрабатывайте ошибку безопасно.
Не рекомендуется
□ Не передавайте непроверенные входные данные командному процессору, даже если полагаете, что пользователь будет вводить обычные данные.
□ Не применяйте подход «все кроме», если не уверены на сто процентов, что учли все возможности.
Стоит подумать
□ О том, чтобы не использовать регулярные выражения для проверки входных данных; лучше написать простую и понятную процедуру проверки вручную.
Грех 6.
Пренебрежение обработкой ошибок
Рекомендуется
□ Проверяйте значения, возвращаемые любой функцией, относящейся к безопасности.
□ Проверяйте значения, возвращаемые любой функцией, которая изменяет параметры, относящиеся к конкретному пользователю или машине в целом.
□ Всеми силами постарайтесь восстановить нормальную работу программы после ошибки, не допускайте отказа от обслуживания.
Не рекомендуется
□ Не перехватывайте все исключения без веской причины, поскольку таким образом можно замаскировать ошибки в программе.