Client-Side Fundamental
  • Добро пожаловать
  • Глава 1 - Начало работы с XSS
    • Браузерная модель безопасности
    • Знакомимся с уязвимостью XSS
    • Более глубокое понимание XSS
    • Опасный псевдопротокол javascript
  • Глава 2 - Защита и Обход для XSS
    • Первая линия обороны от XSS - Sanitization
    • Вторая линия обороны от XSS - CSP (Content Security Policy)
    • Третья линия обороны против XSS - сокращение области воздействия
    • Последние методы защиты от XSS - Trusted Types и встроенный Sanitizer API
    • Обход защитных мер - Обычные способы обхода CSP
    • Обход защитных мер - Mutation XSS
    • Самая опасная XSS - Universal XSS
  • Глава 3 - Атаки без JavaScript
    • Кто сказал, что для атаки обязательно выполнять JavaScript?
    • Prototype Pollution - Эксплуатация цепочки прототипов
    • Может ли HTML влиять на JavaScript - Введение в DOM clobbering
    • Template Injection in Frontend - CSTI
    • CSS Injection - Атака с использованием только CSS (Часть 1)
    • CSS Injection - Атака с использованием только CSS (Часть 2)
    • Можно ли атаковать, используя только HTML
  • Глава 4 - Межсайтовые атаки
    • Same-origin Policy и Same-Site
    • Введение в Cross-Origin Resource Sharing (CORS)
    • Проблемы Cross-Origin безопасности
    • Cross-Site Request Forgery (CSRF)
    • Спаситель от CSRF - Same-site cookie
    • От same-site до главного site
    • Интересная и практичная Cookie Bomb
  • Глава 5 - Другие интересные темы
    • То, что вы видите, это не то, что вы получаете - Clickjacking
    • Эксплуатация MIME Sniffing
    • Атаки на цепочку поставок во фронтенде - Attacking Downstream from Upstream
    • Атаки на веб-фронтенд в Web3
    • Самая интересная атака на побочные каналы фронтенда - XSLeaks (Часть 1)
    • Самая интересная атака на побочные каналы фронтенда - XSLeaks (Часть 2)
Powered by GitBook
On this page
  • More Impactful XSS
  • Practical Application of Cookie Bomb
  • Заключение
  1. Глава 5 - Другие интересные темы

Атаки на веб-фронтенд в Web3

PreviousАтаки на цепочку поставок во фронтенде - Attacking Downstream from UpstreamNextСамая интересная атака на побочные каналы фронтенда - XSLeaks (Часть 1)

Last updated 8 months ago

Когда речь заходит о Web3, большинство людей думают о таких вещах, как криптовалюты, метавселенные или NFTs. Все это построено на базовых технологиях блокчейна и смарт-контрактов, которые формируют совершенно другую систему.

Однако не стоит забывать, что мир Web3 все еще нуждается в точке входа, и этой точкой входа является Web2 — знакомый нам веб.

В этой статье мы рассмотрим несколько реальных примеров атак на мир Web3 с точки зрения Web2.

More Impactful XSS

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

Но что, если уязвимость XSS найдена в мире Web3? Кроме кражи данных, это может привести к краже чего-то более ценного — криптовалют.

В мире криптовалют у каждого есть свой кошелек, и одним из самых известных кошельков в браузере является Metamask. Когда вам будет нужно авторизовать транзакцию или подписать сообщение, вы увидите следующий интерфейс:

Если это транзакция или авторизация для смарт-контракта, вы увидите адрес контракта и другие детали.

Мы все знаем, что не следует слепо принимать транзакции от неизвестных источников или игнорировать подозрительные сайты. Но что, если это известный сайт, такой как PancakeSwap? Когда вы выполняете действие на таком сайте и нажимаете "Подтвердить", Metamask выдает запрос, прося вас одобрить транзакцию. Я полагаю, что 90% людей просто нажмут "Подтвердить".

Однако из-за этого небольшого клика вы можете потенциально потерять значительное количество криптовалюты.

Акт "подписания транзакции" на самом деле представляет собой вызов API кошелька через JavaScript и отображение интерфейса кошелька. Только когда пользователь нажимает "Одобрить", транзакция подписывается с использованием закрытого ключа, что делает транзакцию действительной.

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

Когда вы находите сайт, уязвимый к XSS, вы можете атаковать только этот конкретный сайт. Однако, если вы находите уязвимости в библиотеках, используемых несколькими сайтами, импакт становится гораздо больше.

В статье он описывает нахождение уязвимостей в библиотеке Next.js и @netlify/ipx, которые позволяют проводить XSS-атаки на любом сайте, использующем эти библиотеки.

Netlify — популярная платформа для развертывания сайтов, особенно для сайтов Web3, которые могут быть статическими страницами без традиционного бэкенда. Все функциональности страниц могут быть использоваться с помощью HTML, CSS и JavaScript без необходимости в бэкенд API.

Поэтому через эту уязвимость можно атаковать известные сайты, такие как Gemini или PancakeSwap, используя XSS для вызова интерфейса авторизации смарт-контракта и обмануть пользователей, заставив их кликнуть.

Practical Application of Cookie Bomb

Ранее упомянутая Cookie Bomb также имеет новые последствия в мире Web3.

Многие сайты теперь поддерживают загрузку изображений, и некоторые даже позволяют загружать SVG-файлы.

Так в чем же разница между SVG и другими форматами изображений? Разница в том, что SVG-файлы могут выполнять скрипты, как в приведенном ниже примере:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
  <script type="text/javascript">
    alert("Hello");
  </script>
</svg>

Поэтому, если сайт поддерживает загрузку SVG, существует высокая вероятность эксплуатации уязвимости XSS с использованием SVG.

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

Однако для сайтов NFT ситуация иная.

Для сайтов NFT изображения являются важной частью. Если изображения не могут отображаться, это значительно повлияет на удобство использования всего сайта. Поэтому использование Cookie Bomb для проведения DoS-атаки на изображения имеет больший импакт на сайты связанные с NFT.

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

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

Заключение

В этой статье мы увидели, что продукты Web3 все еще сталкиваются с теми же проблемами безопасности, что и традиционные веб-страницы, и должны быть защищены. Если не обеспечить надлежащую защиту, даже если атаки не связаны со смарт-контрактами, это все равно может причинить определенный ущерб.

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

Спасибо @BrunoModificato за предоставленную идею для этой статьи.

Например, в 2022 году файл JavaScript на сайте NFT под названием PREMINT был скомпрометирован, что привело к тому, что некоторые пользователи непреднамеренно авторизовали смарт-контракт хакера. Для получения более подробной информации, пожалуйста, обратитесь к:

Ранее упомянутые атаки на цепочку поставок также могут быть применены к сайтам Web3. Далее давайте обсудим статью, опубликованную Сэмом Керри в 2022 году:

В статье, опубликованной OtterSec в 2023 году: , они упоминают реальные примеры.

PREMINT NFT Incident Analysis
Exploiting Web3’s Hidden Attack Surface: Universal XSS on Netlify’s Next.js Library
Web2 Bug Repellant Instructions