Коллектив авторов - Защита от хакеров корпоративных сетей

В приложениях Интернет много ошибок, основанных на неверных предположениях о работе сети. Часть из них обусловлена дезинформацией, но большинство – ошибками программирования из-за недостаточного знания программистами принципов работы протокола передачи гипертекстовых файлов HTTP (Hypertext Transfer Protocol). (HTTP – протокол уровня приложений для распределенных информационных систем гипермедиа, позволяющий общаться системам с различной архитектурой. Используется при передаче HTML-файлов по сети страниц WWW и языка гипертекстовой разметки HTML (HyperText Markup Language). Язык HTML – стандартный язык, используемый для создания страниц WWW).

Самая большая ошибка, которую допускают программисты, – необоснованное доверие заголовкам запроса в HTTP-запросе и вера в них как в средство обеспечения безопасности. Заголовок запроса ссылки Referer в HTTP-запросе содержит адрес страницы, на которой находилась ссылка на запрашиваемый документ. Заголовок запроса Referer поддерживается клиентом в клиентских настройках. Так как он создается клиентом, то его можно легко фальсифицировать. Например, при Telnet-обращении к 80 порту (HTTP-порт) Web-сервера можно набрать следующее:

GET / HTTP/1.0

User-Agent: Spoofed-Agent/1.0

Видно, что в заголовке указана фальсифицированная ссылка и подложный агент пользователя. (В сетях агент пользователя (user agent) – прикладной процесс OSI, представляющий пользователя или организацию, который создает, передает и обеспечивает доставку сообщений для пользователя.) Единственно, чему можно доверять из переданной пользователем информации, – это IP-адресу клиента. (Хотя и он может быть фальсифицирован. Подробнее об этом сказано в главе 12.)

Другой недостаток HTTP – зависимость от ограничений представления информации средствами HTML. Зная это, многие разработчики предлагают пользователям выбирать данные из списка (например, из трех элементов). Конечно, совсем не обязательно ограничивать пользователя списком данных, заданным разработчиком. Однажды автор наблюдал достаточно ироничную ситуацию, когда сотрудник Microsoft предлагал использовать списки как эффективный метод борьбы с непредвиденными данными пользователя. Это предлагал человек из группы разработчиков SQL Server, не входивший в группу обеспечения безопасности или разработки Web-решений. От него нельзя требовать больше, чем знание внутренней логики работы SQL-сервера.

Ryan Russell Hal Flynn Ryan Permeah Dan Kaminsky

В HTML-форме описан список, составленный из имен некоторых авторов. Получив HTML-форму, клиентское приложение разрывает соединение, анализирует полученную HTML-форму и предъявляет ее пользователю. После выбора из списка автора клиентское приложение посылает отдельный запрос на Web-сервер с приведенным ниже URL (Uniform Resource Locator – унифицированный указатель информационного ресурса. Стандартизованная строка символов, указывающая местонахождение документа в сети Интернет):

process.cgi?author=Ryan Russell

Все очень просто. Но нет никаких причин, препятствующих посылке другого URL:

process.cgi?author=Rain Forest Puppy

Так обходится предполагаемое «ограничение» HTML-формы. Более того, можно ввести URL, не запрашивая HTML-форму. Для этого следует обратиться к 80 порту Web-сервера по Telnet и сделать запрос вручную. При этом совсем не обязательно обращаться к основной форме. Не следует считать, что полученные на запрос данные – это обязательно результат обработки предыдущей HTML-формы.

Одно из заблуждений, которое автор любит опровергать, – это использование фильтра данных в клиентской части. Многие включают в HTML-формы небольшие сценарии на JavaScript или VBScript, которые контролируют заполнение всех элементов формы. Некоторые предусматривают в сценариях контроль введенных данных: введенные числовые значения действительно числовые и т. д. После такого контроля приложение работает, исходя из предположения об отсутствии ошибок в данных, введенных пользователем, и, следовательно, может сразу передать их системной функции.

На самом деле клиентская часть должна сообщать о проведенных проверках введенных данных. Если читатель не знает, как можно обойти контролирующие ввод пользователя сценарии, то задумайтесь над имеющейся даже у технически непросвещенных людей возможности отключения поддержки сценариев. Например, некоторые корпоративные межсетевые экраны отфильтровывают сценарии HTML-формы. Или злоумышленник может использовать браузеры, не поддерживающие сценарии (например, Lynx).