В современном мире кибербезопасности одной из наиболее сложных задач для исследователей и специалистов по безопасности остается эксплуатация уязвимостей, связанных с межсайтовым скриптингом (XSS). Среди видов XSS-уязвимостей существует особая категория — Self-XSS, которая на первый взгляд кажется менее серьезной и практически бесполезной для реальных атак. Однако современные нововведения в браузерах и веб-стандартах позволяют вновь обратить внимание на Self-XSS, делая его мощным инструментом для злоумышленников. Рассмотрим, как Self-XSS можно сделать действительно опасным, используя современные техники и обходы защиты, включая credentialless iframe, CSRF, Clickjacking и новые браузерные API.Self-XSS традиционно считается проблемой лишь для самого пользователя, который невольно выполняет вредоносный скрипт, введённый в собственную сессию, сталкиваясь с социальной инженерией или фишингом.
Главным препятствием при эксплуатации Self-XSS становится необходимость выполнять вредоносный код именно в аккаунте жертвы, что крайне трудно организовать для третьей стороны. Более того, если атака требует входа в аккаунт злоумышленника для выполнения скрипта, это нивелирует большую часть практической выгоды, так как захват сессии жертвы либо не происходит, либо становится крайне сомнительным.Ситуация начала резко меняться с появлением и поддержкой в браузерах технологии credentialless iframe. Эта новая возможность позволяет создавать iframe, которые загружаются в «безучётном» контексте. Проще говоря, документы, загруженные внутри таких iframe, получают отдельные, эпhemerные контексты без доступа к куки, sessionStorage и другим данным, связанным с исходным пользователем.
По идее, это значительно усложняет атаки, требующие доступа к данным сессии жертвы. Но на практике «credentialless» не означает полной изоляции, а лишь частично меняет правила доступа и разделения данных.Действительно, credentialless iframe остаётся в той же области происхождения (same-origin), что и обычный iframe, что позволяет им обмениваться информацией и взаимодействовать без ограничения полноценного кросс-домена. Это происходит из-за несовершенств реализации концепции opaque origin, которая должна была полностью изолировать такие iframe. Однако из-за проблем с совместимостью и сложностью реализации такой подход реализован частично и не пользуется всеми преимуществами изолированного контекста.
Почему это важно? Если злоумышленник может разместить на странице жертвы credentialless iframe, он получает возможность создать скрытый или видимый фрейм с вредоносным содержанием, который сможет взаимодействовать с родительским документом в том же происхождении, что и целевой сайт. Возникает возможность получить доступ к cookie жертвы, локальному хранилищу и выполнять скрипты на его behalf, ставя под угрозу безопасность, даже если исходная уязвимость была классифицирована как Self-XSS.В условиях подобной архитектуры можно использовать классическую технику CSRF (Cross-Site Request Forgery) на этапе входа в систему. Если сайт жертвы не защищен от CSRF, злоумышленник может создать форму, которая автоматически отправит данные входа, включая вредоносную полезную нагрузку, в браузер жертвы. Используя возможность управления window.
name, можно буквально внедрить вредоносный скрипт, который выполнится в контексте iframe и захватит данные сессии. В таком сценарии，комбинация Self-XSS и CSRF позволяет удалить базовые ограничения, которые раньше мешали использовать Self-XSS в полноценной атаке.Одной из проблем защиты является распространённое заблуждение, что CAPTCHA (тест «Я не робот») может эффективно блокировать CSRF-атаки. На практике это неверно. CAPTCHA лишь проверяет, что форму заполнял живой человек, но не гарантирует, что запрос не инициируется из другого окна или устройства.
Соответственно, если атака реализована с использованием WebSocket-сервера и удалённого взаимодействия, когда злоумышленник получает CAPTCHA-токен отдельно, то уязвимость остаётся открытой. Такой подход позволяет обойти условные меры защиты и делать атаку практически автоматической.Если CSRF-защита отсутствует или затруднена, злоумышленник может использовать технику Clickjacking. В данном случае цель — заставить пользователя войти в аккаунт злоумышленника, при этом вводя данные не на его сайте, а на сайте жертвы, в credentialless iframe с наложенным прозрачным оверлеем. Эти действия выглядят для пользователя вполне легитимно, и он часто не замечает подвоха.
Несмотря на то что Clickjacking не является новым методом, применение его вместе с современными iframe повышает эффективность взлома, особенно если сайт не использует защиту от встраивания, такую как X-Frame-Options: Deny.Однако что делать, если внедрение iframe вообще запрещено политиками безопасности сайта? Эту задачу облегчает новая веб-API fetchLater, которая была представлена в 2025 году. API позволяет откладывать выполнение HTTP-запросов до момента закрытия страницы или перехода пользователя на другой ресурс. Таким образом, атака может быть запланирована и выполнена позже, даже после того, как браузер закроет текущую сессию. Это даёт возможность обойти запреты вроде X-Frame-Options и выполнять постфактум запросы, сохраняя контекст с введёнными cookies.
Применение fetchLater в контексте Self-XSS позволяет злоумышленнику подготовить цепочку запросов для изменения уровней доступа и прав пользователя, например, повысить свои права до администратора. Эти отложенные запросы будут отправлены в момент, когда пользователь снова активирует сайт и восстановит сессию. Злоумышленник, проведя такую подготовку, получает возможность эксплуатировать уязвимость без текущего активного соединения и даже после выхода из системы.Таким образом, современные возможности браузеров и протоколы существенно расширяют арсенал техник, позволяющих превратить ранее неопасные или недостаточно практичные уязвимости Self-XSS в полноценные атаки с серьёзными последствиями. Credentialless iframe создают новый уровень взаимодействия, объединяя полноценные преимущества same-origin и частичное разделение хранения данных, что в сумме упрощает эксплуатацию.
Важно отметить, что для успешной реализации таких атак требуется минимальное участие пользователя: он должен перейти по вредоносной ссылке или посетить специально подготовленную страницу. После этого все процессы на стороне злоумышленника могут осуществляться практически автономно благодаря современным API, скрытым iframe и техникам обхода защиты. Это делает Self-XSS новым полем для исследований и требует переосмысления подходов к обработке, обнаружению и ликвидации подобных уязвимостей на современных веб-платформах.В итоге, возврат Self-XSS как серьёзной угрозы показывает, что устаревшие представления о безопасности и классификации уязвимостей могут быть опасны. Сложный ландшафт браузерных технологий и их неоднозначное внедрение создают новые, неожиданные возможности атаки, которые нельзя игнорировать.
Инженерам по безопасности, разработчикам и всему сообществу исследователей необходимо глубоко понимать новые браузерные возможности, такие как credentialless iframe и fetchLater, а также использовать комплексный подход к защите от XSS и CSRF.Для веб-разработчиков это значит обязательное применение защитных механизмов вроде предусловий CSRF, строгих заголовков X-Frame-Options и Content Security Policy (CSP), а также регулярное тестирование приложений на наличие потенциальных Self-XSS, которые теперь могут быть превращены в полный Stored XSS. Эффективная борьба с такими уязвимостями требует постоянного обновления знаний и инструментов, использования современных средств анализа безопасности и своевременного реагирования на появляющиеся новые варианты атак.Таким образом, изменения в браузерах и интернете не уменьшают, а скорее увеличивают реальность угрозы Self-XSS, делая её современной, актуальной и достойной серьёзного изучения и внимания со стороны всех участников процесса обеспечения информационной безопасности.
