Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ

Для стандартных вызовов API, с помощью которых происходит обращение к командным процессорам, имеет смысл написать собственные обертки, которые фильтруют входные данных по списку разрешенных символов и возбуждают исключение, если что–то не так. Это не должно быть единственным средством контроля, поскольку часто необходима более тщательная проверка. Однако в качестве первой линии обороны сойдет, к тому же и реализовать совсем нетрудно. Можно либо заменить «плохие» функции обертками прямо в библиотеке, либо пропустить исходный текст через простейшую программу поиска, найти все места, где они встречаются, и быстро провести контекстную замену.

□ «How То Remove Metacharacters From User–Supplied Data in CGI Scripts»: www.cert.org/tech_tips/cgi_metacharacters.html

Рекомендуется

□ Проверяйте все входные данные до передачи их командному процессору.

□ Если проверка не проходит, обрабатывайте ошибку безопасно.

Не рекомендуется

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

□ Не применяйте подход «все кроме», если не уверены на сто процентов, что учли все возможности.

Стоит подумать

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

Безопасность подвергается серьезной угрозе, когда программист не уделяет должное внимание обработке ошибок. Иногда программа может оказаться в некорректном состоянии, но чаще все заканчивается отказом от обслуживания, так как приложение просто «падает». Эта проблема не утрачивает значимости даже в таких современных языках, как С# и Java, только в них аварийное завершение программы происходит из–за необработанного исключения, а не из–за того, что автор забыл проверить код возврата.

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

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

Уязвим любой язык, в котором функция извещает об ошибке с помощью кода возврата, например ASP, PHP, С и С++, а также языки, полагающиеся на исключения: С#, VB.NET и Java.

Есть шесть способов впасть в этот грех:

□ раскрытие излишней информации;

□ игнорирование ошибок;

□ неправильная интерпретация ошибок;

□ бесполезные возвращаемые значения;

□ обработка не тех исключений, что нужно;

□ обработка всех исключений.

Рассмотрим каждый в отдельности.

Раскрытие излишней информации

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

Игнорирование ошибок

Функция возвращает код ошибки не просто так, а чтобы вызывающая программа могла отреагировать. Согласны, некоторые значения кодов возврата носят чисто информационный характер и зачастую необязательны. Например, значение, возвращаемое функцией printf, проверяется очень редко; если оно положительно, то равно числу выведенных символов, а–1 означает ошибку. Честно говоря, для вызывающей программы ошибка в printf не слишком существенна.

Но чаще возвращаемое значение важно. Например, в Windows есть несколько функций, позволяющих сменить учетную запись, от имени которой работает программа: ImpersonateSelf(), ImpersonateLogonUser() и SetThreadToken(). Если любая из них возвращает ошибку, значит, олицетворение не состоялось, и поток продолжает работать от имени того же пользователя, что и весь процесс.

Или возьмем ввод/вывод. Если вы вызываете функцию fopenQ, а она не может открыть файл (его не существует или к нему нет доступа), и вы не обрабатываете ошибку, то все последующие вызовы fwrite() или fread() тоже завершатся неудачно. А если вы читаете из файла данные, а потом как–то их используете, то приложение может «грохнуться».