На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

ПОДРОБНОСТИ ОБ АТАКЕ ПОДМЕНЫ ГИПЕРССЫЛОК

Как уже обсуждалось в главе 8, при создании SSL-соединения броузер и сервер совместно используют один и тот же протокол. С его помощью производится
идентификация сервера и (возможно, но не обязательно) клиента. Однако для атаки подмены гиперссылок важна только стадия идентификации сервера. Во время используемого в SSL обмена протоколами сервер предоставляет броузеру свой сертификат. Сертификат сервера — это структура с цифровой подписью, в
которой расположены открытый ключ и некоторые другие атрибуты сервера.
В настоящее время в сертификатах SSL используются DNS (domain-name server). Вместо полного имени DNS в сертификат могут включаться символы шаблона (wildcard). Например, вместо имени www.brd.ie может стоять *.brd.ie. Чтобы до­казать броузеру, что только этому серверу принадлежит соответствующий лич­ный ключ, используется корректная передача протокола и предоставление пра­вильного сертификата. Благодаря этому броузер может считать, что именно этому серверу принадлежит право на использование представленного имени DNS. Важ­но, чтобы вы поняли, что протокол SSL не является непреодолимым препят­ствием для атаки подмены гиперссылок. Наоборот, остановить эту атаку могут
содержание сертификата и пользовательский интерфейс броузера.
ДЕЙСТВИЕ АТАКИ ПОДМЕНЫ ГИПЕРССЫЛОК
Для успешного проведения этой атаки очень важно, чтобы пользователь не ука­зывал имена DNS или указатели url а использовал гиперссылки. Дело в том, что в современной версии стандарта SSL проверяется только часть ответ­ственная за сервер, а не гиперссылка, по которой щелкнули мышью. Ведь ссылка может принимать совершенно неприемлемые с точки зрения значения (вроде «Этот путь ведет в Jamsa Press») или может вообще представлять собой графи­ческое изображение.
Точно так же как имена DNS являются объектом атаки подмены DNS (при этом сервер DNS предоставляет ложную информацию об адресе другого сервера), идентификаторы URL являются объектом атак подмены гиперссылок. В этом случае страница содержит ложную информацию об имени DNS указанного URL. Обе атаки подмены приведут пользователя к чужому серверу. Однако с техни­ческой точки зрения подмена гиперссылок более проста, чем подмена имен DNS. Например, хакер может передать броузеру такую строку:
<А HREF=https://www.hacker.com/infogatherer/>This way to free books!</A>
Подведя указатель мыши к такой гиперссылке, вы увидите надпись «This way to free books!» («Здесь расположены бесплатные книги!»). Но если щелкнуть по ней мышью, то ссылка направит вас на другой безопасный сервер - hacker.com в каталог infogatherer. Современные броузеры автоматически обнаружат, исполь­зуется безопасное соединение или нет. При этом они отобразят цельные ключи и т. д. Однако все это не мешает хакеру продолжать свое надувательство. При помощи несложных уловок (они описываются далее) хакер может заставить бро­узер сообщать пользователю о том, что используется безопасное соединение с нужным сервером.
Итак, щелкнув по ссылке, пользователь продолжает верить, что он все еще использует безопасное соединение. Но это, к сожалению, не так. И конечно же, каталог infogatherer не содержит никаких книг. Более того, если пользова­тель действительно подвергается атаке со стороны хакера, то хакер постарается сделать так, чтобы страница, к которой перешел пользователь, выглядела как настоящая Web-страница. При этом там может стоять странный запрос о номере
кредитной карточки, на который необходимо ответить для приобретения бес­платных книг. Однако если пользователь «пороется» в различных меню броузера и просмотрит источник документа или информацию о нем, то он обнаружит, что сервер, с которым он соединен, — это совсем не тот сервер, который был
определен во время идентификации.
Как это ни странно, но все более широкое использование сертификатов сильно упрощает задачу хакера. Дело в том, что с ростом количества серверов с серти­фикатами у хакеров появляется больше мест, в которые можно отправить неза­дачливого Web-путешественника. Кроме того, многие пользователи стараются обойтись без надоедливых диалоговых окон, появляющихся при каждом перехо­де на новую Web-страницу. Однако от атак не застрахованы и более осторожные пользователи — ведь если соединение и документ безопасны, то это совсем не значит, что так оно и есть. Другими словами, проверка соединения становится
бессмысленной.
Несмотря на все современные крупнокалиберные средства обороны, не суще­ствует инструментов для обнаружения атаки подмены гиперссылок. В лучшем случае журнал регистрации броузера может показать, что была использована команда GET (к «настоящему» серверу), а за ней следовала еще одна такая же команда (к «вымышленному» серверу). Если повезет, то в кэше останется копия подделанной Web-страницы. Однако хакер может легко заставить броузер уда­лить эту копию. Для этого достаточно воспользоваться командой PRAGMA (см. гла­ву 6). Зачем же нужна вторая команда GET] Дело в том, что первая команда возвращает некорректный или измененный результат. К сожалению, у пользо­вателя нет возможности выяснить (даже при помощи самых лучших журналов регистрации), что вторая команда была инициализирована удаленным серве­ром. Вы могли последовать за закладкой или в другое окно для второй команды. Даже если вы сможете доказать, что не следовали за закладками, подделанная страница могла прийти из кэша (включая и соседние кэши вашего провайдера) или в результате действия первой команды GET. Предположим, что «поддель­ные» сайты принадлежат хакеру. Однако и это нельзя доказать, даже если вы сможете повторить все шаги, приведшие вас к «поддельному» сайту.
Хакер наверняка не собирается допускать вас к своему засекреченному сайту. Ведь при этом вы получите прямую улику — его сертификат. Поэтому злоумыш­ленник, скорее всего, отправит жертву на чей-либо (уже взломанный хакером)
почтовый ящик SSL. Более того, хакер может послать незадачливого пользова­теля на необходимый тому безопасный сервер, однако совсем в другое место. Другими словами, вместо каталога /securepage он попадет в каталог /attackpage. Подобные вещи могут происходить только на виртуально назначенном ведущим узлом (virtually-hosted) Web-сайте или на сайтах, где URL указывают на сцена­рии CGI или классы Java, часть которых находится под легальным управлением хакера. (Несмотря на все свои достоинства, SSL не предоставляет никаких средств защиты от подобных посягательств; основная цель этого стандарта — идентифи­кация сайтов.)
МЕТОДЫ  БОРЬБЫ   С АТАКОЙ ПОДМЕНЫ ГИПЕРССЫЛОК
Если вы уже используете основанные на идентификации сервера Web-приложе­ния (например, для продажи апплетов Java), то наверняка вам не хочется ждать, пока ваш провайдер программного обеспечения Internet предоставит какие-либо средства защиты. Единственно правильным в этом случае будет следующее ре­шение: сделайте так, чтобы броузеры ваших пользователей начинали свой путь по вашему сайту с безопасной страницы. Благодаря этому они смогут доверять своим первоначальным ссылкам. Безопасная страница — это страница, чьей целостности можно доверять. Реально это HTML-файл или SSL-страница. показана модель доступа к безопасной странице.
начальная страница
Модель доступа к безопасной странице.
Если нужно, чтобы броузер пользователя открывался на SSL-странице, то вам следует послать URL этой страницы при помощи каких-либо трудных (или даже невозможных) к перехвату средств. Например, для этого можно воспользовать­ся флоппи-диском или обычным письмом. В противном случае страница будет открыта для атак. Все ссылки этой страницы должны вести к надежным сайтам; более того, желательно, чтобы все они являлись SSL-ссылками. Вам следует определить, какие сайты можно отнести к надежным, а какие нет. Для этого советуем воспользоваться следующими критериями:
1. Сайт полностью защищен от атак и перехвата страниц.
2. Сайт обслуживает ссылки только на полностью защищенные сайты.
Большинство сайтов не удовлетворяют первому критерию. Таким образом, ре­шение в виде доступа к безопасным страницам скорее подходит для приложений корпоративных сетей, отгороженных от Internet при помощи брандмауэра. Кро­ме того, это решение может использоваться в специализированных приложениях Internet, в которых пользователи могут получить доступ только к Internet-сайтам определенной корпорации (т. е. им не нужен полный доступ к Internet).
Вместо этого можно поместить на Web-страницы достаточно уникальный для сайта объект. Примерами уникальных объектов являются сертификаты VeriSign Java и
Microsoft Authenticode* Так как сертификаты VeriSign создаются при помощи вычисления смешанного значения, а в качестве входных данных используется Web-страница и привязанные к ней апплеты Java, то хакеру будет очень трудно подделать этот сертификат. Более подробное описание цифровых сертификатов имеется в главе 5. показана Web-страница и ее сертификат.
Web-cmpamnu с новым (не известным броузеру) сертификатом.
Рассмотрим еще один метод защиты. После уста­новки этой программы пользователи будут всегда видеть, кто владелец отобра­жаемого в броузере сайта. По умолчанию программа должна выводить на экран диалоговое окно с информацией. Однако в ее состав можно включить параметр (доступ к которому должен осуществляться при помощи пароля), с помощью которого можно будет запретить отображение окна на экране. Кроме того, ин­формация о сертификате может быть отображена и в декорациях окна броузера после того, как он установит соединение с сервером. Однако не нужно отобра­жать эту информацию в строке состояния. Дело в том, что последнюю можно изменить при помощи апплетов Java или сценариев VBScript либо JavaScript. Предоставьте пользователю возможность постоянно получать информацию о вла­дельце сайта. показано, где можно разместить подобное про­граммное расширение.
Информацию о сертификате можно поместить рядом с установленными по умолчанию ссылками Internet Explorer.
К сожалению, информация о сертификате вряд ли поможет пользователю избе­жать атак подмены, если подмена перенаправит запрос клиента или ответ серве­ра от одной страницы к другой странице одного и того же Web-сайта (например, от одного сценария CGI к другому или от одного апплета Java к другому и т. д.).
Четвертый метод предотвращения атак — это использование «надежных закла­док». В этом случае сотрудники службы внешней безопасности могли бы под­вергнуть каждую такую закладку тщательной проверке, и только потом помес­тить ее в индивидуальные файлы закладок. К тому же каждая такая закладка должна распространяться вручную (т. е. без использования сети). Надежная за­кладка должна быть как-то отмечена в файле закладок — пользователь должен четко отличать надежные закладки от обычных. В этом методе вам также при­дется создать программное расширение броузера, поддерживающее надежные закладки. Любая надежная закладка должна проходить от текстовой гиперссыл­ки или изображения к содержащимся в броузере именам доменов или URL. Например, она может выглядеть так:
"*Jamsa Press*:*.jamsa.com"
Если после этого броузер встретит ссылку со словами Press», то он проверит сертификат сервера в домене jamsa.conm удостоверится в том, что присоеди­нен именно к fxmmjamsa.com, Если же броузер соединяется с доменом третьей стороны (другими словами, с доменом, не принадлежащим правой части стро­ки закладки), то он предупредит пользователя о том, что этот домен не соответ­ствует ожидаемому. При помощи решения надежных закладок пользователи мо­гут сконфигурировать охранников (safeguard) броузеров так, чтобы они облада­ли доступом к определенным «локальным» службам. Кроме того, данный метод защищает компанию от «внутренних» врагов — не очень квалифицированных работников компании, передающих важную информацию по обычным каналам.
На самом деле надежная закладка является средством для безопасного преобра­зования (mapping) текстовой ссылки в URL имени домена. Каждый из описан­ных ранее методов защиты пытается создать свое средство преобразования или проверить существующие методы преобразования. Однако есть и другие методы
безопасного преобразования адресов Web. Например, можно создать службы безопасного каталога Internet, который можно поместить поверх существующих
протоколов работы с сертификатами. К сожалению, создание служб безопас­ных каталогов, скорее всего, натолкнется на искусственный слой окольных средств (обмана) между ссылкой, «сущностью» сайта и самим сайтом. Это не только заставляет отказаться от некоторых решений, но и затрудняет обеспече­ние безопасности ссылок. И наконец, ни одно из описанных здесь решений нельзя приспособить для получения доступа ко всем услугам сети. Более того, ни одно из решений не предоставляет возможности уберечь пользователей от перенаправления броузера в пределах одного сайта.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика