Реклама:

* Значения, возвращаемые формой из вашего приложения (например, cookies и строковые параметры запросов).

■ Заголовки HTTP.

■ Идентификационные данные пользователя.

■ Параметры методов и значения полей/свойств независимо от того, были ли они заданы внутри приложения.

■ Все данные, которые не были скомпилированы в вашу сборку.

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

Необходимость подтверждения входных данных

Почему же так важно подтверждать входные данные? Одна из основных причин очевидна; никто не хочет оперировать ложными данными. Ваше приложение их обрабатывает, принимает соответствующие решения на их основе, после чего данные попадают в серверное хранилище. Другим приложениям в сети также может потребоваться эта информация, что в итоге приведет к их некорректной работе или даже к сбою.

Г^Н ПРИМЕЧАНИЕ Принцип так называемых скрытых атак, или атак второго уровня, состоит в том, что злонамеренно сформированные данные вводятся во фронтальные системы (например, в Web-приложения), атакуя не клиентскую часть, а только то приложение, которое обрабатывает эти данные. Примером может служить система ввода данных, сохраняющая пользовательскую информацию без ее подтверждения или кодирования. Если, обрабатывая данные, приложение рассматривает их как безопасные и использует для отображения таких данных интерфейс HTML, то код сценария, добавленный злоумышленником, может быть выполнен в вашей внутренней сети. Такой вид атаки называется межсайтовой атакой сценария второго уровня. Межсайтовые сценарии мы рассмотрим далее в этой главе.

Даже если не касаться вопросов защиты, подтверждение входных данных способствует корректной функциональности приложения, определяя данные, которые можно обрабатывать надлежащим способом, и отбрасывая все остальное. Более того, оно гарантирует ожидаемое качество собранных данных и очистку хранилища от неправильных данных, причем, это потребует меньше затрат, нежели введение жестких правил ввода.

А как поступать с теми уязвимыми местами, которые появились в приложении из-за логических ошибок, а не при попытках обработки «неожиданных бонусов» из сети? Такие данные не следует считать злонамеренными, поскольку изначально они не предназначены для создания серьезных проблем в приложении.

Помимо этой очевидной причины можно назвать ряд других. Существует целая группа атак с использованием формирования входных данных, которые могут обманным путем заставить ваше приложение выполнять несвойственные ему операции. Эти атаки выполняются путем вложения программных кодов и возникают там, где есть проблемы с данными и каналами управления.

Данные и каналы управления

Выполняемые ветви приложения всегда зависят от двух факторов:

• написанного кода;

• входных данных из внешних источников, например данных пользователя или сетевой службы.

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


⇐ Предыдущая страница| |Следующая страница ⇒