Ukryty pasażer w sesji bankowej: jak przekierowania przez Taboola kierowały ruch do Temu

Wprowadzenie do problemu / definicja

Bezpieczeństwo nowoczesnych aplikacji webowych nie zależy już wyłącznie od jakości własnego kodu i konfiguracji serwera. Coraz większe znaczenie ma to, jakie skrypty, piksele i usługi zewnętrzne są uruchamiane w przeglądarce użytkownika oraz gdzie finalnie trafia generowany przez nie ruch. Opisany przypadek pokazuje ryzyko tzw. pierwszego zaufanego skoku, gdy organizacja ufa jednemu dostawcy, ale nie ma pełnej widoczności dalszych przekierowań wykonywanych już po stronie klienta.

W praktyce oznacza to, że nawet na zalogowanych stronach bankowych lub finansowych może dojść do komunikacji z domeną, której operator serwisu nie przewidział jako końcowego odbiorcy danych telemetrycznych. Nie musi to oznaczać klasycznego wycieku haseł czy numerów rachunków, ale może prowadzić do niejawnego profilowania aktywności użytkownika w kontekście sesji uwierzytelnionej.

W skrócie

Podczas audytu europejskiej platformy finansowej ustalono, że komponent powiązany z Taboola inicjował żądanie na zalogowanych stronach użytkowników, po czym odpowiedź HTTP 302 przekierowywała ruch do endpointu śledzącego w domenie Temu. Szczególne znaczenie miał nagłówek umożliwiający uwierzytelnione żądania międzydomenowe, co mogło sprzyjać przesyłaniu identyfikatorów i ciasteczek w komunikacji cross-origin.

To przykład zagrożenia, którego nie wykrywają standardowe kontrole skupione wyłącznie na liście zaakceptowanych dostawców. Formalnie zaufany partner może bowiem stać się punktem wejścia do szerszego łańcucha zależności reklamowych i trackingowych.

Kontekst / historia

Współczesne serwisy internetowe bardzo często korzystają z narzędzi reklamowych, analitycznych, rekomendacyjnych i pomiarowych dostarczanych przez zewnętrznych partnerów. Model ten jest wygodny biznesowo i operacyjnie, ale tworzy zależności, które trudno w pełni prześledzić. Zaufanie do jednego dostawcy często obejmuje także jego podwykonawców, partnerów technologicznych i endpointy, które pojawiają się dopiero w czasie wykonywania kodu w przeglądarce.

W badanym przypadku problem został zauważony podczas audytu przeprowadzonego w lutym 2026 roku. Ustalenia wskazały, że ruch inicjowany na stronach zalogowanego użytkownika nie kończył się na zatwierdzonej domenie pośrednika, lecz był przekierowywany dalej do zewnętrznego systemu śledzącego. To ważny sygnał ostrzegawczy dla branż regulowanych, gdzie strony po zalogowaniu powinny być traktowane jako obszar podwyższonego zaufania.

Analiza techniczna

Mechanizm działania był relatywnie prosty, ale trudny do uchwycenia przez klasyczne zabezpieczenia. Przeglądarka użytkownika na zalogowanej stronie wykonywała żądanie GET do domeny powiązanej z Taboola. Następnie serwer odpowiadał kodem HTTP 302 Found, a przekierowanie prowadziło do endpointu API w domenie Temu.

W analizowanym łańcuchu istotną rolę odgrywał nagłówek Access-Control-Allow-Credentials: true. W kontekście żądań cross-origin ma on znaczenie dla sytuacji, w których przeglądarka może przesyłać poświadczenia, takie jak ciasteczka czy inne identyfikatory sesyjne. Samo jego występowanie nie oznacza jeszcze kompromitacji konta, ale w połączeniu z ruchem z obszaru uwierzytelnionego zwiększa ryzyko korelacji aktywności użytkownika z zewnętrznym profilem trackingowym.

Problem wynika z faktu, że wiele mechanizmów kontrolnych ocenia głównie punkt początkowy komunikacji. Jeżeli pierwsza domena znajduje się na liście dozwolonej polityki bezpieczeństwa, cały proces może wyglądać na zgodny z oczekiwaniami. Tymczasem rzeczywisty cel końcowy może ujawniać się dopiero po przekierowaniu lub dynamicznym wywołaniu po stronie klienta.

• Zapory WAF skupiają się głównie na ruchu kierowanym do aplikacji, a nie na pełnym zachowaniu przeglądarki użytkownika.
• Analiza statyczna wykrywa obecność dozwolonego skryptu lub piksela, ale nie pokazuje dynamicznych przekierowań wykonywanych w runtime.
• Polityki CSP często kontrolują źródła początkowe, lecz nie zawsze zapewniają pełną widoczność końcowych destynacji ruchu.
• Monitoring aplikacyjny nie musi obejmować mapowania zależności fourth-party, czyli podmiotów ukrytych za bezpośrednim dostawcą.

To sprawia, że do powstania istotnego ryzyka nie jest potrzebna klasyczna luka typu XSS, RCE czy przejęcie sesji. Wystarczy, że zewnętrzny komponent obecny na stronie zalogowanego użytkownika przekaże metadane, identyfikatory przeglądarki lub informacje o kontekście wizyty do nieoczekiwanego odbiorcy.

Konsekwencje / ryzyko

Najpoważniejsze skutki dotyczą prywatności, zgodności regulacyjnej i nadzoru nad łańcuchem dostaw aplikacji webowej. Nawet jeśli nie doszło do bezpośredniego ujawnienia danych logowania, sama możliwość powiązania aktywności użytkownika banku z zewnętrznym systemem śledzącym może rodzić poważne pytania o legalność, przejrzystość i zakres przetwarzania danych.

• Utrata kontroli nad środowiskiem stron zalogowanych, które powinny pozostawać maksymalnie odseparowane od ekosystemu reklamowego.
• Ryzyko naruszenia zasad minimalizacji danych i rozliczalności wobec regulatorów oraz audytorów.
• Ryzyko reputacyjne wynikające z połączenia sesji bankowej z mechanizmami profilowania reklamowego.
• Ryzyko fourth-party, gdy zatwierdzony dostawca korzysta z dalszych integracji nieuwzględnionych w procesie oceny.
• Niska wykrywalność incydentu, jeśli organizacja nie monitoruje pełnych łańcuchów żądań wykonywanych w przeglądarce.

W sektorach finansowych, medycznych i innych środowiskach wrażliwych podobne przypadki mogą mieć znaczenie nie tylko techniczne, ale również prawne i biznesowe. Odpowiedzialność organizacji nie kończy się bowiem na wskazaniu, że zaakceptowano jedynie bezpośredniego partnera.

Rekomendacje

Organizacje powinny przyjąć założenie, że kontrola nad skryptami zewnętrznymi nie może ograniczać się do sprawdzenia nazwy dostawcy i podstawowej listy domen. Potrzebne jest połączenie środków technicznych, procesowych i architektonicznych.

• Maksymalnie ograniczać obecność narzędzi reklamowych, rekomendacyjnych i trackingowych na stronach zalogowanych.
• Monitorować pełne łańcuchy runtime, w tym przekierowania 3xx, wywołania fetch i XHR oraz dynamicznie ładowane zasoby.
• Rozszerzyć proces vendor risk management o relacje third-party i fourth-party.
• Regularnie przeglądać polityki CSP, ustawienia connect-src, zasady cookies oraz reguły dotyczące poświadczeń cross-origin.
• Uzupełnić klasyczne testy bezpieczeństwa o analizę zachowania rzeczywistej przeglądarki po zalogowaniu.
• Włączać zespoły AppSec, privacy i legal do wspólnej oceny komponentów zewnętrznych w obszarach uwierzytelnionych.
• Utrzymywać aktualną inwentaryzację wszystkich domen, endpointów i przekierowań obserwowanych po stronie klienta.

Najważniejsza zmiana dotyczy podejścia: zaufanie do jednego dostawcy nie może automatycznie obejmować całego łańcucha zależności, który ujawnia się dopiero w czasie wykonywania kodu w przeglądarce użytkownika.

Podsumowanie

Opisany przypadek pokazuje, że realne zagrożenia dla aplikacji webowych coraz częściej wynikają nie z klasycznych błędów programistycznych, lecz z braku widoczności nad ruchem inicjowanym przez zewnętrzne komponenty. Przekierowanie ruchu z zalogowanych stron bankowych przez zaufany piksel do zewnętrznego endpointu trackingowego ujawnia słabość modeli bezpieczeństwa opartych wyłącznie na liście zaakceptowanych partnerów.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że analiza runtime, kontrola zależności fourth-party i ścisła separacja obszarów marketingowych od transakcyjnych stają się dziś równie ważne jak tradycyjne testy podatności. W środowiskach regulowanych taka zmiana perspektywy nie jest już opcją, lecz koniecznością.

Źródła

1. The Hacker News — Hidden Passenger? How Taboola Routes Logged-In Banking Sessions to Temu — https://thehackernews.com/2026/04/hidden-passenger-how-taboola-routes.html
2. MDN Web Docs — Access-Control-Allow-Credentials — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials
3. MDN Web Docs — Content Security Policy (CSP) — https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
4. OWASP — Third-Party JavaScript Management Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
5. PCI Security Standards Council — PCI DSS Documentation Library — https://www.pcisecuritystandards.org/document_library/