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

  • На форуме работает ручное одобрение пользователей. Это значит, что, если Ваша причина регистрации не соответствует тематике форума, а также Вы используете временную почту, Ваша учётная запись будет отклонена без возможности повторной регистрации. В дальнейшем - пожизненная блокировка обоих аккаунтов за создание мультиаккаунта.
  • Мы обновили Tor зеркало до v3!
    Для входа используйте следующий url: darkv3nw2...bzad.onion/
  • Мы вновь вернули telegram чат форуму, вступайте, общайтесь, задавайте любые вопросы как администрации, так и пользователям!
    Ссылка: https://t.me/chat_dark_time

AnGel

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

AnGel

Администратор
Команда форума
27 Авг 2015
3,413
2,025
Один шаг от пассивной XSS уязвимости до внедрения AJAX червя
Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!
*
Множество раз встречаюсь с мнением что пассивная XSS уязвимость не представляет большой опасности и беспокоиться по этому поводу особо не стоит. И несмотря на то, что отчасти это действительно так(если сравнивать с другими, более катастрофическими ошибками), возможность внедрения своего кода на уязвимый сайт, даже требующая существенных дополнительных действий по обману пользователя может привести к серьёзным последствиям, в частности к возможности полностью перехватить дальнейшие действия пользователя.
Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!


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

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

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

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

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

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

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

Не допускать наличие XSS уязвимостей —
Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!
и автоматическим тестированием, а также использование
Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!
с правильной политикой экранирования данных извне.

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

О нас

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

    Dark-Time 2015 - 2024

    При поддержке: XenForo.Info

Быстрая навигация

Меню пользователя