1. Do you speak English? Use the English version of the site! Link
    Скрыть объявление
Скрыть объявление
Здравствуй гость! После регистрации на ресурсе, ты сможешь скачивать материалы с форума и участвовать в его жизни! Для регистрации откройте соответствующую форму или нажмите на эту ссылку.

От пассивной xss уязвимости до внедрения ajax червя

Тема в разделе "Взлом", создана пользователем AnGel, 13.10.2015.

  1. AnGel

    AnGel Администратор
    Команда форума

    Дек 04 2016 в 03:24
    Регистрация:
    27.08.2015
    Сообщения:
    1.780
    Симпатии:
    1.296
    Один шаг от пассивной XSS уязвимости до внедрения AJAX червя
    Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок!*
    Множество раз встречаюсь с мнением что пассивная XSS уязвимость не представляет большой опасности и беспокоиться по этому поводу особо не стоит. И несмотря на то, что отчасти это действительно так(если сравнивать с другими, более катастрофическими ошибками), возможность внедрения своего кода на уязвимый сайт, даже требующая существенных дополнительных действий по обману пользователя может привести к серьёзным последствиям, в частности к возможности полностью перехватить дальнейшие действия пользователя.
    Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок!

    Маленькое отступление — если бы существовала возможность получить из браузера код произвольной страницы в сети, проблема безопасности была бы гораздо серьёзнее, к счастью все современные браузеры не позволяют совершать cross-site запросы. Но и это можно обойти, передавая запросы промежуточному приложению находящемуся на том же домене что и страница с червём и выполняющем функцию качалки контента.

    В простейшем случае это приложение реализуется в одну строчку на php. Боевой же вариант как минимум должен уметь кешировать скачиваемые данные, чтобы минимизировать возросшее в 2 раза время получения клиентом данных, ну а в совсем идеальном случае — поддерживать приём/передачу cookies, и совершать запросы через набор прокси, чтобы не выдавать себя чересчур часто светя ip в логах.

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

    Хотя такой метод и позволяет сделать много пакостей, он требует слишком много действий для первоначального завлечения человека на страниц ловушку. Не говоря уже о том, что такая страница очень быстро окажется во всевозможных чёрных списках браузеров, А что если страницей-ловушкой окажется чужая, совершенно безопасная на первый взгляд страница со знакомого пользователю домена. Вот тут и вступает в бой возможность внедрить свой код посредством XSS уязвимости на чужом сайте.

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

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

    И что со всем этим делать.

    Не допускать наличие XSS уязвимостей — Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок! и автоматическим тестированием, а также использование Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок! с правильной политикой экранирования данных извне.

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