XSS без XSS

Автор: Marsel [marsel roses.ru] aka Phoenix

Введение

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

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

Вторым вариантом уязвимости, является ситуация, когда часть HTTP GET запроса выводится на этой же html странице тому же пользователю без надлежащей фильтрации. Как правило – это ситуации, когда без надлежащей фильтрации выводится идентификатор сессии или другие GET параметры.

И я не буду приводить опасности классических типов уязвимости, типа XSS, так как об этих опасностях написано довольно много.

Теперь рассмотрим некоторые ситуации, когда уязвимость отсутствует в явном виде.

Сбор статистики

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

Так, например, на многих форумах, вставить изображение можно используя конструкцию [IMG]http://site/image[/IMG]

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

Теперь представим себе, что вместо изображение находиться некоторый скрипт [IMG]http://site/image.php[/IMG], который делает следующее

1. охраняет информацию о запросе
2. выводит заголовок: Content-type: image/jpeg (для PJEG изображения)
3. выводит собственно, содержание изображения.

Теперь, учитывая, что в большинстве случаев в качестве поля HTTP-REFERER, HTTP запроса при запросе картинок, броузер отсылает URL документа, на котором вставлена картинка, то при помощи скрипта можно собрать следующие данные

1. IP адрес (включая заголовки X-FORWARDED_FOR и тп.)
2. Каждую страницу, посещенную каждым пользователем (при условии, что на ней имеется ссылка на данное изображение)
3. Поле User-Agent пользователя

Наверное, результативнее всего для сбора статистики в большинстве форумов, такой URL изображения, следует задать в качестве URL-а аватара. Можно бы было предположить, что для того, чтобы исключить такую возможность, на сервере можно разрешить размещение только изображений, имеющих соответствующее расширение файла - .jpg или только .gif Однако, излишне любопытный пользователь сможет настроить HTTP сервер таки образом, чтобы файлы .jpg к примеру, тоже считались и обрабатывались как PHP скрипты.

Более того, PHP может быть сконфигурирован таким образом, что никакая информация об интерпретаторе PHP не посылалась в заголовке HTTP ответа. Таким образом, подобный сбор статистики может быть реализован абсолютно прозрачно для сервера и клиентов.

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

Конечно, всю эту информация можно собрат и из логов HTTP сервера, на котором находится такое “изображение”, но ведение логов в скрипте кажется мне более избирательным.

Похищение реквизитов пользователя.

Продолжаем рассматривать эту же ситуацию. В некоторой системе (форуме), разрешено включать каким либо образом в сообщения картинки со сторонних серверов.

Каждый раз, когда каждый пользователь открывает html страницу с таким сообщением, его броузер делает запрос на сервер, который может контролироваться хакером, с целью получения тела изображения.

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

Например, там может быть написано о сбое авторизации, и прочие фразы, создание которых относится уже к социо-инженерии.

Внимание. Есть данные, что броузер IE 6.x, может не запрашивать пароль в такой ситуации. Запрашивает пароль броузер mozilla всех версий, IE 5.x.

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

Скрипт, генерирующий этот заголовок и принимающий данные может при повторном запросе (отслеживается по ip), вернуть содержимое изображение, без ответа о неудачной авторизации.

Таким образом, после того, как пользователь введет имя и пароль, страница откроется в обычном виде.

Как защита от подобного нападения, после отправки сообщения, сервер может запрашивать с удаленного сервера все изображения, имеющиеся в документе, и оставлять из в сообщении, только если они действительно будут являться правильными изображениями, и возвращаться с кодом 200.

Однако, нападающий сможет легко отличить запрос сервера (по ip адресу, времени запроса и тп.), и возвратить серверу правильное содержание изображения.

Аналогично, можно полностью скрыть, что на стороне сервера работает скрипт.

На этапе добавление сообщения, серверу невозможно узнать, добавлено нормальное изображение, или нет.

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

DDOS

Ситуация та же. Любой пользователь любым образом имеет возможность добавить в текст сообщения изображение со стороннего сайта, которое будет доступно всем, открывающим эту html страницу

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

В первую очередь я имею ввиду SQL инъекцию, с возможностью внедрения benchmark() функции, таким образом, что один запрос сильно нагрузит уязвимый сервер.

Об уязвимости типа SQL инъекция и в том числе об использовании фунункции benchmark в SQL запросе для проведения DOS атаки, рассказано в этой статье http://www.securitylab.ru/45438.html

Размещая в рассматриваемом форуме (предполагаем, что он имеет большую посещаемость), большое количество сообщений, содержащих изображения с URL-ом на самом деле эксплуатирующую уязвимость в третьем сайте.

Этот метод атаки, на первый взгляд кажется не эффективным по нескольким причинам.

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

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

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

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

Лучше всего для таких целей подходит ссылка на аватар.

После того, как накоплена значительная база таких сообщений, скрипт, ранее, возвращающий содержимое изображения, станет возвращать заголовок HTTP ответа 301 – moved, с указанным в Location заголовке URL, эксплуатирующим уязвимость в третьем сайте.

Конечно, с этого момента, изображение открываться не будет. Но, каждый посетитель, открывающий любую страницу с таким изображением сам того не ведая будет участвовать в DDOS атаке на такой скрипт.

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

Когда htmlspecialchars() не помигает

Теперь рассмотрим другую ситуацию. К примеру, в некоторой системе (форуме), некоторыми методами в каждом сообщении можно оставить ссылку (

 <a href=…>…</a>

), на произвольный URL.

Так, например, может использоваться слеующие конструкции [URL=…]…[/URL].

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

Например, для вывода собственно URL ссылки и текста ссылки используется функция наподобие функции PHP htmlspecialchars().

Таким образом, выбраться за пределы атрибута href, невозможно. И невозможно изменить реакции на события OnMouseClick или OnMouseOver.

Другими словами, казалось бы, уязвимость отсутствует.

Однако, что если сделать вот так?

 
[URL=javascript:alert(document.cooke)]click me[/URL]

По указанным правилам этот текст конвертируется в следующую строку при выводе в броузер:

<a href=”javascript:alert(document.cooke)”>click me</a>

Далее, при клике на эту ссылку, как ни странно, выполниться внедренный JavaScript код. Более того, выполниться он в контексте “неуязвимого” сайта, что влечет за собой все неприятности уязвимости XSS.

В частности, это может использоваться для кражи COKIE целевого пользователя.

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

Например, пробелы в JavaScript коде, могут замениться на последовательности /**/.

А от использования кавычек спасет функция string.fromCharCode(), которая принимает коды символов и возвращает строку.

Для исключения этой уязвимости достаточно фильтровать слово script в URL ссылки.

Действия администратором

Вернемся к нашей ситуации, с возможностью внедрения изображений в сообщения.

Допустим, для выполнения некоторых действий администратором системы или модератором, происходит переход по некоторой ссылке.

Так, например, допустим, для удаления сообщения, администратору необходимо кликнуть на ссылку типа http://site/forum/delete-post.php?id=12345, где 12345 – это идентификатор сообщения.

Теперь представим себе ситуацию, что хакер оставит на форуме сообщение с изображением, имеющим именно такой URL.

Результатом будет то, что как только администратор прочитает это сообщение, его броузер сделает запрос к данному URL, и, в том числе, передаст все аутификационые данные (COOKIE) на сервер. Предполагается, что администратор в момент прочтения такого сообщения (например, отправленные ему приватным посыльным), аутифицирован на форуме.

В результате, целевое сообщение будет удалено, незаметно для администратора.

Допустим, в результате какой либо фильтрации, в сообщениях на форуме невозможно вставлять изображения с таким URL.

Тогда хакеру поможет “фокус” с Location.

Нападающему достаточно будет вставить в сообщение изображение, находящееся на контролируемом сайте. Контролируемый нападающим сервер при запросе данного изображения должен ответить заголовком 301 (или 302) moved, с Location полем, со значением целевым URL = http://site/forum/delete-post.php?id=12345.

В результате, при запросе этого изображения, броузер администратора обратиться по данному URL прозрачно для администратора будет выполнено некоторое действие.

Как и ранее, нападающий может полностью скрыть факт выполнения скриптов на сервере, и, кроме того, любые фильтры возможно присутствующие в системе (форуме), могут быть обойдены указанным способом.

Более того, просматривая URL изображения (в свойствах изображения в броузере), администратора не заметит ничего удивительного. URL может действительно выгладить как URL обычного изображения.

И, кроме того, если в системе предусмотрены методы контроля, и, для выполнения действий администратором, необходимо, чтобы HTTP REFERER, переданный броузером принадлежал форуму, то и эта проверка обходится автоматически. Дело в том, что при запросе изображения, расположенного на сайте, серверу на котором расположено изображение передается HTTP_REFERER равный URL-у страницы с изображением. А при переходе по Location, с заголовком 301 (302) Moved, HTTP-REFERER сохраняется.

Внимание. К подобному типу атаки уязвимы ВСЕ системы (форумы, чаты), разрешающие вставку в сообщения изображений со сторонних сайтов, в случае, если для выполнения некоторых действий администратором (модератором), хватит простого HTTP GET запроса.

Теперь рассмотрим более сложную ситуацию. Для выполнения некоторых действий администратором необходимо отправить HTTP POST запрос. Примером может служить отправка сообщения от имени администратора, либо другие действия вплоть до перевода определенных пользователей между группами и наделения их привилегиями администратора.

Хакер может разместить ссылку ([URL=xxx]yyy[/URL]) на некоторое изображение или URL, с целью заманить администратора по указанному URL.

Например, URL может быть похож на адрес картинки (*.jpg), чтобы не вызвать дополнительных подозрений у администратора.

При переходе по этому URL, администратору может выводиться форма со скрытыми полями, содержащая все необходимые данные, и отправляться методами JavaScript автоматически после загрузки.

Для поведения скрытой атаки, форма может находится в iframe объекте, который в свою очередь находится в невидимом слое.

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

На мой взгляд описанные возможности являются очень опасными по нескольким причинам.

1) существует огромное количество продуктов, уязвимых к такого рода атакам

2) атака очень легко осуществима

3) атака может быть проведена незаметно для администратора

4) атака может быть проведена с минимальными взаимодействиями с администратором (модератором) системы

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

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

Заключение

Иногда паранойя – это полезно