Agent przeglądarkowy nie musi znać hasła do WhatsAppa ani przejmować pliku cookie, żeby narobić szkód. Wystarczy, że działa w środowisku, w którym WhatsApp Web jest już zalogowany, potrafi sterować kartami przeglądarki i traktuje treść odwiedzanej strony jako wskazówki istotne dla wykonywanego zadania.
To zmienia model zagrożenia. Zwykła strona WWW jest ograniczona mechanizmami bezpieczeństwa przeglądarki i nie może po prostu odczytać zawartości karty z web.whatsapp.com. Agent może jednak sam przejść do tej karty, rozpoznać interfejs i wykonać działanie jako użytkownik. Jeżeli wcześniej da się nakłonić go do niepożądanego kroku przez tekst znajdujący się na stronie, mamy problem znany jako indirect prompt injection, a w szerszym ujęciu — agent hijacking.
Najważniejsza różnica brzmi więc: atakujący nie musi przełamywać zabezpieczeń WhatsAppa. Próbuje wykorzystać uprawnienia, które użytkownik już przekazał agentowi.
Złośliwa strona nie musi kraść sesji — wystarczy, że przekona agenta do jej użycia
W klasycznym scenariuszu ataku na sesję przeglądarkową interesują nas przede wszystkim cookies, tokeny uwierzytelniające, XSS, przejęcie urządzenia albo wyłudzenie kodu logowania. W przypadku agenta dochodzi nowa warstwa: sterowanie decyzją systemu, który ma legalny dostęp do zalogowanych aplikacji.
Wyobraźmy sobie zwykłe zadanie: agent ma znaleźć ofertę, porównać informacje na kilku stronach i przygotować wynik. Jedna z odwiedzonych witryn zawiera treść przygotowaną nie dla człowieka, lecz dla modelu. Może być umieszczona w tekście strony, opisie produktu, danych pobieranych przez aplikację czy innym elemencie analizowanym przez agenta.
Jeżeli system nie oddziela wystarczająco mocno poleceń użytkownika od danych pochodzących z internetu, agent może uznać obcą treść za instrukcję. Sam mechanizm jest dobrze znany z prompt injection: dane zaczynają wpływać na tok wykonywania zadania zamiast pozostawać wyłącznie materiałem do analizy.
Krytyczny moment następuje wtedy, gdy agent ma jednocześnie możliwość:
-
otwierania i przełączania kart,
-
klikania elementów interfejsu,
-
wpisywania tekstu do formularzy i edytorów,
-
korzystania z aplikacji, w których użytkownik jest już uwierzytelniony,
-
wykonywania operacji bez każdorazowej, jednoznacznej zgody człowieka.
W takim modelu złośliwa witryna sama nadal nie ma prawa wejść do WhatsAppa. Robi to agent — jako działający w imieniu użytkownika operator przeglądarki.
To istotny detal techniczny. Same Origin Policy nie przestaje działać. Strona z domeny atakującego nie otrzymuje magicznie dostępu do DOM-u WhatsApp Web. Problem leży wyżej: agent może mieć możliwość świadomego przejścia pomiędzy tymi domenami tak samo jak człowiek siedzący przed ekranem.
Jeśli WhatsApp Web jest już połączony z kontem, ponowne wpisanie hasła przy każdej wiadomości nie jest wymagane. Połączone urządzenia można sprawdzić i odłączyć z poziomu sekcji Połączone urządzenia w aplikacji WhatsApp. To właśnie dlatego pozostawienie aktywnej sesji w środowisku dostępnym dla szeroko uprawnionego agenta zwiększa konsekwencje błędu.
Nie oznacza to, że każda strona może automatycznie zmusić każdego agenta do wysłania wiadomości. Skuteczność zależy od architektury konkretnego produktu, jego filtrów, zakresu narzędzi, sposobu potwierdzania operacji i odporności modelu na treści zewnętrzne. Prompt injection nie daje gwarancji wykonania polecenia. Tworzy natomiast klasę ryzyka, której nie da się sprowadzić do tradycyjnego pytania: „czy strona może wykraść moje cookie?”.
Najgroźniejsze jest połączenie trzech rzeczy: obcej treści, szerokich uprawnień i braku potwierdzenia
W praktycznych analizach agentów największy problem rzadko wynika z jednego błędu. Ryzyko gwałtownie rośnie dopiero wtedy, kiedy spotykają się trzy elementy.
Pierwszy to niezaufane dane wejściowe. Strona internetowa, wiadomość e-mail, dokument PDF, komentarz użytkownika albo opis produktu powinny być dla agenta danymi. Nie instrukcjami zmieniającymi cel zadania.
Drugi to nadmierne uprawnienia. Agent przeznaczony do wyszukiwania informacji nie potrzebuje swobodnego dostępu do komunikatorów, bankowości, panelu administracyjnego sklepu i służbowej poczty. Jeżeli wszystkie te aplikacje są dostępne w tej samej sesji przeglądarki, pojedyncze nieprawidłowe zachowanie ma znacznie większy zasięg.
Trzeci element to brak skutecznego human-in-the-loop, czyli rzeczywistego zatwierdzenia działania przez człowieka.
Nie każde okno „Czy zezwolić?” rozwiązuje problem. Potwierdzenie ma sens dopiero wtedy, gdy pokazuje użytkownikowi konkretnie:
-
jaka operacja zostanie wykonana,
-
w jakiej aplikacji,
-
wobec jakiego odbiorcy,
-
jaka treść zostanie wysłana,
-
czy operacja obejmuje jedną czy wiele osób.
Komunikat w rodzaju „Agent chce kontynuować zadanie” ma niewielką wartość ochronną. Człowiek zatwierdza wtedy proces, którego efektu nie widzi.
Jeszcze gorzej wygląda zatwierdzanie całej serii działań jednym kliknięciem. Przy operacjach nieodwracalnych albo wychodzących poza przeglądanie danych — wysłaniu wiadomości, opublikowaniu wpisu, usunięciu pliku czy zmianie ustawień konta — zgoda powinna być związana z konkretnym skutkiem, a nie z ogólnym prawem do klikania.
W przypadku WhatsAppa konsekwencja jest szczególnie niewygodna, bo wiadomość wychodzi z prawdziwego konta użytkownika. Odbiorca widzi znany numer i istniejącą historię rozmowy. Jeżeli treść dotrze do klientów, współpracowników czy rodziny, problem przestaje być czysto techniczny.
Możliwe następstwa obejmują między innymi:
-
wysłanie fałszywej lub kompromitującej wiadomości do istniejącego kontaktu,
-
podszywanie się pod właściciela konta w rozpoczętej już rozmowie,
-
ujawnienie informacji, które agent wcześniej odczytał w innym miejscu,
-
rozesłanie tej samej treści do wielu odbiorców,
-
rozpoczęcie dalszej socjotechniki z konta cieszącego się zaufaniem.
Szczególnie zły projekt to taki, w którym agent jednocześnie czyta niekontrolowaną treść z internetu i ma automatyczne prawo wykonywania operacji na uwierzytelnionych kontach. Filtr treści jest wtedy tylko jedną linią obrony. Jeśli zawiedzie, za nim nie ma już bariery uprawnień.
Jak ograniczyć ryzyko w praktyce: najpierw odseparuj sesje, potem ogranicz agenta
Najprostszego zabezpieczenia nie trzeba szukać w skomplikowanym systemie wykrywania prompt injection. Nie udostępniaj agentowi sesji, której nie potrzebuje do zadania.
Jeżeli agent służy do researchu w internecie, uruchamianie go w tym samym profilu Chrome, Edge czy innej przeglądarki, w którym otwarte są WhatsApp Web, Gmail, bankowość i panele firmowe, jest złym modelem operacyjnym.
Lepsza hierarchia zabezpieczeń wygląda następująco.
Priorytet 1: oddziel profil lub środowisko agenta.
Agent wykonujący zadania na niezaufanych stronach powinien korzystać z osobnego profilu przeglądarki, kontenera lub innego środowiska bez aktywnych sesji do usług, których nie potrzebuje. To zabezpieczenie działa także wtedy, gdy model źle zinterpretuje zawartość strony.
Priorytet 2: stosuj minimalne uprawnienia.
Jeśli narzędzie pozwala określić, z jakich domen, aplikacji lub funkcji agent może korzystać, dostęp należy nadawać zadaniowo. Agent analizujący cenniki nie potrzebuje funkcji wysyłania wiadomości.
Priorytet 3: wymagaj zatwierdzenia przed działaniem zewnętrznym.
Wysłanie wiadomości, publikacja, zakup, usunięcie danych czy zmiana ustawień powinny zatrzymywać automatyczny proces. Użytkownik musi zobaczyć konkretną operację przed jej wykonaniem.
Priorytet 4: traktuj zawartość stron jako niezaufane dane.
Polecenia znajdujące się w odwiedzanej witrynie nie powinny zmieniać celu zadania ustalonego przez użytkownika. Sam zapis w systemowym promptcie nie jest jednak zabezpieczeniem wystarczającym. Potrzebna jest jeszcze kontrola narzędzi i uprawnień.
Priorytet 5: prowadź historię działań agenta.
Przy incydencie potrzebna jest odpowiedź na proste pytania: jaką stronę agent wcześniej odwiedził, kiedy przełączył kartę, co wpisał i jaka operacja została zatwierdzona. Bez takiego śladu analiza zdarzenia szybko zmienia się w zgadywanie.
W firmie dochodzi do tego jeszcze jeden problem: używanie prywatnego profilu przeglądarki do służbowej automatyzacji. To wygodne przez pierwszych kilka dni, bo wszystko „już jest zalogowane”. Później staje się źródłem trudnych do kontrolowania zależności. Agent otrzymuje faktycznie więcej dostępu, niż wynika z jego formalnej roli.
Jeżeli istnieje podejrzenie, że agent wykonał nieautoryzowaną operację w WhatsAppie, kolejność reakcji również ma znaczenie. Najpierw należy zatrzymać dalszą automatyzację i sprawdzić Połączone urządzenia na koncie WhatsApp. Nieznane albo niepotrzebne urządzenia trzeba wylogować. Następnie sprawdza się wysłane rozmowy i zakres potencjalnego incydentu, a dopiero później wraca do analizy strony lub promptu, który mógł go wywołać.
Samo wylogowanie WhatsAppa nie usuwa jednak przyczyny. Jeśli agent nadal ma zbyt szerokie uprawnienia, następny incydent może dotyczyć poczty, dysku w chmurze albo innej zalogowanej aplikacji.
FAQ
Czy złośliwa strona może bezpośrednio odczytać moje rozmowy z karty WhatsApp Web?
Nie powinna uzyskać takiego dostępu tylko dlatego, że jest otwarta w sąsiedniej karcie. Standardowe mechanizmy izolacji originów przeglądarki ograniczają bezpośredni dostęp między domenami. Zagrożenie opisywane tutaj polega na wykorzystaniu agenta, który sam potrafi przełączać się między stronami i działać w ich interfejsach.
Czy do takiego nadużycia trzeba wykraść cookie albo token WhatsAppa?
Nie. W scenariuszu agentowym sednem problemu może być właśnie to, że token nie zostaje wykradziony. Agent korzysta z istniejącej, prawidłowo uwierzytelnionej sesji użytkownika.
Czy zamknięcie karty WhatsApp Web wystarczy?
Nie należy traktować tego jako pełnego zabezpieczenia. Istotne jest, czy konto pozostaje połączone z urządzeniem i czy agent może ponownie otworzyć usługę w tym samym profilu. Aktywne urządzenia można skontrolować w WhatsAppie w sekcji Połączone urządzenia.
Czy dodatkowe potwierdzanie każdego wysłania wiadomości rozwiązuje problem?
Znacznie ogranicza ryzyko, ale tylko wtedy, gdy potwierdzenie pokazuje rzeczywiste działanie: odbiorcę i treść wiadomości. Ogólna zgoda na „kontynuację pracy agenta” jest dużo słabszą barierą.
Czy osobny profil przeglądarki ma sens, jeśli agent ma dobre zabezpieczenia przed prompt injection?
Tak. To jedna z najmocniejszych praktycznych warstw ochronnych, ponieważ zmniejsza konsekwencje błędu modelu. Nawet jeśli agent źle zinterpretuje złośliwą stronę, nie wykorzysta sesji WhatsAppa, której w jego środowisku po prostu nie ma.
Co zrobić, gdy podejrzewam, że agent już wysłał coś bez mojej zgody?
Najpierw przerwij jego działanie i skontroluj wysłane rozmowy oraz Połączone urządzenia. Odłącz zbędne sesje, ustal odbiorców i zakres wysłanych treści, a następnie przeanalizuj historię działań agenta. Nie zaczynaj od szukania „złośliwego promptu”, pozostawiając agentowi aktywne uprawnienia — najpierw ogranicza się możliwość dalszych działań.
Więcej informacji na: https://sajo.pl
Jeżeli masz dziś usunąć tylko jeden błąd, przestań uruchamiać agenta przeglądarkowego na tym samym profilu, w którym pozostają aktywne sesje WhatsAppa i innych wrażliwych usług. Najpierw odseparuj środowisko i sprawdź połączone urządzenia; dopiero potem poprawiaj filtry prompt injection i mechanizmy zatwierdzania.
