Інтеграція ІІ-асистентів у браузери — від Copilot у Microsoft Edge та Gemini в Google Chrome до Comet від Perplexity — змінила спосіб роботи з вебом: штучний інтелект підсумовує сторінки, відповідає на запитання та діє як «агент», що взаємодіє з сайтами замість користувача. Дослідження Cato Networks показало, що ця зручність відкрила й новий клас загроз: техніку HashJack, яка використовує символ # у URL як прихований канал для prompt injection і обходить класичні засоби захисту.
Як працює атака HashJack через URL-фрагмент #
У стандарті HTTP усе, що розташоване після символу # в адресному рядку, називається фрагментом URL (hash) і не передається на вебсервер. Ця частина обробляється виключно на стороні браузера й зазвичай застосовується для навігації по сторінці, прокрутки до якорів або роботи SPA-додатків.
HashJack експлуатує саме цю особливість. Зловмисник бере повністю легітимний URL, додає в кінець символ «#», а після нього — прихований промпт для ІІ: інструкції, команди, запити на витік даних. Для сервера такий запит виглядає абсолютно нормальним, тому що фрагмент до нього просто не доходить. Натомість вбудований ІІ-асистент у браузері бачить повний URL разом із hash-фрагментом і включає цей текст до контексту обробки.
Символ # як прихований канал керування мовною моделлю
Таким чином HashJack перетворює кінець URL після «#» на прихований канал управління ІІ-моделлю. Коли користувач просить, наприклад, «підсумувати сторінку» або «пояснити цей документ», ІІ отримує не тільки вміст сайту, а й приховані інструкції з URL-фрагмента. Виникає опосередкована ін'єкція промптів: модель виконує не явний запит користувача, а сценарій, який тихо «прошитий» у посиланні.
HashJack як новий тип опосередкованої prompt injection
Prompt injection уже фігурує в OWASP Top 10 для LLM-додатків як один із базових ризиків: атакувальник формує промпт так, щоб модель порушила політики безпеки, розкрила дані або виконала небажані дії. Особливість HashJack у тому, що це перша задокументована техніка, яка робить будь-який довірений сайт вектором prompt injection без його компрометації.
Ризик зміщується з рівня «зловмисник контролює контент сайту» до рівня «зловмисник контролює посилання, яким ділиться з користувачем». Посилання з доданим «#» і довгим текстом можна непомітно вбудувати в листи, чати, документи, рекламу. Домени можуть бути справжніми, сертифікати — дійсними, а от поведінка ІІ-асистента виявиться вже контрольованою атакувальником.
Практичні сценарії атак на ІІ-браузери
Під час тестування фахівці Cato Networks продемонстрували, що в ІІ-браузерах з агентними можливостями, зокрема Comet від Perplexity, атака HashJack дозволяє ініціювати витік даних користувача на сервери, підконтрольні зловмисникам. Модель, слідуючи інструкціям із hash-фрагмента, може збирати вміст сторінки, елементи історії взаємодії, а в окремих сценаріях — навіть конфіденційні дані, які користувач вводив у форми, та відправляти їх назовні.
В інших варіантах експлуатації ІІ-асистенти змушувалися генерувати фішингові посилання, зміщувати інтерпретацію даних на користь атакувальника або підсовувати хибні поради. Особливо критичними є галузі з високим рівнем відповідальності — медицина, фінанси, право. Якщо ІІ, керуючись прихованим промптом у URL, порадить небезпечну дозу препарату чи ризикову інвестиційну операцію, наслідки виходять за рамки «цифрового» інциденту.
Реакція Google, Microsoft і Perplexity на HashJack
Про проблему HashJack постачальників було проінформовано завчасно: Perplexity — у липні, Google і Microsoft — у серпні. За даними Cato Networks, Google класифікувала таку поведінку як «очікувану», присвоїла їй низький пріоритет і відмовилася змінювати роботу Chrome та Gemini.
Microsoft і Perplexity натомість випустили оновлення своїх ІІ-браузерів, намагаючись мінімізувати ризики опосередкованої prompt injection через URL-фрагменти. У Microsoft підкреслили, що протидія таким атакам розглядається як безперервний процес, а кожна нова техніка ін'єкції промптів аналізується окремо.
Чому класичні засоби захисту не бачать атаку HashJack
Більшість традиційних засобів безпеки вебдодатків — WAF, системи моніторингу HTTP-трафіку, IDS/IPS, проксі-шлюзи — просто не бачать вміст після символу «#», оскільки він не передається мережею. Отже, сигнатурний аналіз, серверні фільтри URL і антифішингові механізми не мають можливості відсіяти шкідливий промпт.
Додатково багато рішень безпеки фокусуються на самому сайті чи файлах, але майже не враховують нову зв'язку «браузер + ІІ-асистент», яка обробляє прихований контекст. У результаті HashJack опиняється поза полем зору як класичного аналізу трафіку, так і більшості корпоративних засобів контролю доступу до вебресурсів.
Як захиститися: рекомендації для організацій та користувачів
Ефективна протидія HashJack вимагає багаторівневого підходу. На організаційному рівні варто впровадити політики використання ІІ-інструментів: формувати список дозволених ІІ-асистентів у браузерах, централізовано налаштовувати їхні параметри безпеки, за потреби відключати найризиковіші функції (автоматичні агенти, доступ до зовнішніх сервісів, завантаження файлів).
Важливий технічний контроль — фільтрація й нормалізація URL на стороні клієнта: у розширеннях браузера, агентському ПЗ чи на захищених веб-шлюзах. Довгі або нетипові фрагменти після «#», особливо якщо це розгорнуті текстові інструкції, доцільно блокувати, скорочувати або принаймні помічати як ризикові для ІІ-обробки.
Окремий напрямок — моніторинг активності ІІ-асистентів. Організаціям варто логувати звернення до ІІ, аналізувати аномальні відповіді (несподівані зовнішні посилання, спроби передати дані третім сторонам), інтегрувати DLP-рішення для контролю того, які саме дані можуть залишати корпоративний периметр через ІІ-сервіси.
Критичною залишається й освіта користувачів. Наявність знайомого домену та «поважного» логотипа не гарантує, що відповіді ІІ безпечні. Будь-які рекомендації щодо фінансів, здоров'я, юридичних дій варто перевіряти за незалежними джерелами і не сприймати як автоматично коректні лише тому, що їх згенерував браузерний ІІ.
Розповсюдження HashJack демонструє, що із зростанням популярності ІІ-браузерів зростає й інтерес атакувальників до контексту мовних моделей. Щоб зменшити ризики, вже зараз варто переглянути ланцюжок довіри «користувач — браузер — ІІ-асистент — зовнішній сервіс», увімкнути моніторинг і контроль ІІ-інструментів та навчати співробітників уважно ставитися навіть до, здавалося б, «звичайного» кліку за посиланням із символом «#» наприкінці.
