Шрифт:
В январе 2004 года организация «Открытый проект по безопасности Web–приложений» (Open Web Application Security Project – OWASP) опубликовала документ, озаглавленный «Десять самых критичных уязвимостей Web–приложений» (www.owasp.org/documentation/topten.html). Ниже 19 описанных в этой книге грехов сопоставляются с тем, что перечислены в документа OWASP.
Приложение В. Сводка рекомендаций
В этом приложении сведены наши советы о том, что следует делать, чего не следует, а о чем стоит подумать. Мы решили включить его, потому что иногда разработчику во время написания программы хочется не читать всю книгу, а просто вспомнить, что надо и чего не надо делать.
Грех 1.
Переполнение буфера
Рекомендуется
□ Тщательно проверяйте любой доступ к буферу за счет использования безопасных функций для работы со строками и областями памяти.
□ Пользуйтесь встраиваемыми в компилятор средствами защиты, например флагом /GS и программой ProPolice.
□ Применяйте механизмы защиты от переполнения буфера на уровне операционной системы, например DEP и РаХ.
□ Уясните, какие данные контролирует противник, и обрабатывайте их безопасным образом.
Не рекомендуется
□ Не думайте, что компилятор и ОС все сделают за вас, это всего лишь дополнительные средства защиты.
□ Не используйте небезопасные функции в новых программах.
Стоит подумать
□ Об установке последней версии компилятора C/C++, поскольку разработчики включают в генерируемый код новые механизмы защиты.
□ О постепенном удалении небезопасных функций из старых программ.
□ Об использовании строк и контейнерных классов из библиотеки С++ вместо применения низкоуровневых функций С для работы со строками.
Грех 2.
Ошибки, связанные с форматной строкой
Рекомендуется
□ Пользуйтесь фиксированными форматными строками или считываемыми из заслуживающего доверия источника.
□ Проверяйте корректность всех запросов к локали.
Не рекомендуется
□ Не передавайте поступающие от пользователя форматные строки напрямую функциям форматирования.
Стоит подумать
□ О том, чтобы использовать языки высокого уровня, которые в меньшей степени уязвимы относительно этой ошибки.
Грех 3.
Переполнение целых чисел
Рекомендуется
□ Проверяйте на возможность переполнения все арифметические вычисления, в результате которых определяется размер выделяемой памяти.
□ Проверяйте на возможность переполнения все арифметические вычисления, в результате которых определяются индексы массивов.
□ Пользуйтесь целыми без знака для хранения смещений от начала массива и размеров блоков выделяемой памяти.
Не рекомендуется
□ Не думайте, что ни в каких языках, кроме C/C++, переполнение целого невозможно.
Грех 4.
Внедрение SQL–команд
Рекомендуется
□ Изучите базу данных, с которой работаете. Поддерживаются ли в ней хранимые процедуры? Как выглядит комментарий? Может ли противник получить доступ к расширенной функциональности?
□ Проверяйте корректность входных данных и устанавливайте степень доверия к ним.
□ Используйте параметризованные запросы (также распространены термины «подготовленное предложение» и «связывание параметров») для построения SQL–предложений.
□ Храните информацию о параметрах соединения вне приложения, например в защищенном конфигурационном файле или в реестре Windows.
Не рекомендуется
□ Не ограничивайтесь простой фильтрацией «плохих слов». Существует множество вариантов написания, которые вы не в состоянии обнаружить.
□ Не доверяйте входным данным при построении SQL–предложения.
□ Не используйте конкатенацию строк для построения SQL–предложения даже при вызове хранимых процедур. Хранимые процедуры, конечно, полезны, но решить проблему полностью они не могут.
□ Не используйте конкатенацию строк для построения SQL–предложения внутри хранимых процедур.