Logowanie do portalu przechwytującego – co to jest i jak działa?

Logowanie do portalu przechwytującego polega na krótkim uwierzytelnieniu użytkownika w sieci Wi‑Fi, zanim uzyska on dostęp do internetu. Najczęściej widzisz to jako stronę z regulaminem, formularzem logowania lub płatnością otwierającą się zaraz po podłączeniu do hotspotu. Takie rozwiązanie wiąże się zarówno z wygodą, jak i z ryzykiem, jeśli zostanie źle zaimplementowane lub spreparowane przez cyberprzestępców. Warto poznać, jak dokładnie działa ten mechanizm i jak zarządzać nim bezpiecznie.

Co to jest portal przechwytujący?

Portal przechwytujący (ang. captive portal) to specjalna strona startowa, która pojawia się po podłączeniu do publicznej lub firmowej sieci Wi‑Fi i „przechwytuje” ruch użytkownika, zanim zostanie on wypuszczony do internetu. Sieci na lotniskach, w hotelach, samolotach czy urzędach korzystają z takiego rozwiązania, żeby pokazać regulamin, wymusić logowanie, ograniczyć ruch lub zliczyć użytkowników. Technicznie jest to element konfiguracji punktu dostępowego, zapory lub serwera proxy, który przekierowuje żądania HTTP/HTTPS na stronę logowania.

Operator sieci może w portalu zbierać dane (np. adres e‑mail, pokój hotelowy, numer biletu), wyświetlać reklamy, egzekwować limity czasu i transferu czy wymagać akceptacji warunków. Z punktu widzenia urządzenia z Androidem, ChromeOS czy Windows, taka sieć na początku nie daje pełnego dostępu do internetu – system widzi ją jako sieć „z logowaniem” i uruchamia wbudowaną aplikację do obsługi portalu.

Portal przechwytujący to warstwa pośrednia między użytkownikiem a internetem – dopóki nie zalogujesz się lub nie zaakceptujesz warunków, cały ruch sieciowy jest kontrolowany i blokowany.

Jak działa logowanie do portalu przechwytującego?

Przy każdym połączeniu z siecią z portalem przechwytującym zachodzi kilka powtarzalnych kroków – od konfiguracji IP po przekierowanie na stronę logowania i weryfikację użytkownika. Choć całość wygląda dla użytkownika jak „po prostu otwarta strona”, w tle pracuje kilka warstw infrastruktury sieciowej i systemowych modułów, takich jak Network Stack w Androidzie.

Jak urządzenie wykrywa portal przechwytujący?

Urządzenie najpierw otrzymuje adres IP przez DHCP, a następnie system sprawdza, czy ma prawdziwy dostęp do internetu, czy znajduje się za portalem. W Androidzie od wersji 5.0 robi to komponent NetworkMonitor, który wysyła sondy HTTP/HTTPS do znanych hostów weryfikacyjnych (np. connectivitycheck.gstatic.com). Gdy sieć przekieruje taką sondę na stronę logowania zamiast zwykłej odpowiedzi 204/200, system uznaje, że trafił na portal przechwytujący i wyświetla okno logowania.

Od Androida 11 część logiki przeniesiono do modułu Network Stack, który jest aktualizowany jako moduł Mainline. Dzięki temu system może dostosowywać sposób wykrywania portali do nowych standardów – np. obsługiwać opcję DHCP 114 opisaną w RFC7710bis, która wskazuje adres URL interfejsu API portalu. W takiej konfiguracji punkt dostępowy wysyła urządzeniu bezpośrednio adres JSON‑owego API, z którego system pobiera informacje o stanie portalu, adres logowania i czasie trwania sesji.

Jak działa Captive Portal API?

Interfejs Captive Portal API, opisany w standardzie RFC 8908, porządkuje komunikację między siecią a urządzeniem. Zamiast liczyć na „przypadkowe” przekierowanie sondy HTTP, sieć udostępnia dedykowany punkt końcowy HTTPS, który zwraca strukturę JSON z informacją, czy użytkownik jest już online, czy musi się uwierzytelnić. Przykładowa odpowiedź zawiera pola takie jak:

• captive – informacja, czy wymagane jest logowanie,
• user-portal-url – adres strony logowania lub płatności,
• venue-info-url – link do strony z informacjami o miejscu (np. hotel, lotnisko),
• seconds-remaining – czas, przez jaki sesja ma pozostać aktywna.

Na tej podstawie Android może pominąć tradycyjne sondy i od razu otworzyć okno logowania, jeśli captive ma wartość true. Gdy w odpowiedzi pojawia się seconds-remaining, system informuje użytkownika, ile czasu zostało do końca sesji i kiedy trzeba się przeautoryzować. Dzięki temu logowanie staje się przewidywalne, a wykrywanie portali mniej zawodne.

Jak ChromeOS pokazuje logowanie do portalu?

W ChromeOS wykrywanie portalu działa podobnie, ale administrator może zarządzać tym z poziomu konsoli Google. W sieciach zarządzanych (np. firmowych, szkolnych) wykrywanie portali przechwytujących bywa celowo wyłączone, bo nad ruchem czuwa zapora lub serwer proxy. Jeśli jednak konfigurujesz sieć gościnną, warto włączyć tę funkcję, żeby użytkownicy od razu zobaczyli okno logowania.

Aby włączyć wykrywanie, administrator w Konsoli administracyjnej Google wybiera urządzenia, przechodzi do sekcji sieci Wi‑Fi, znajduje daną sieć i w części „Ustawienia portalu przechwytującego” zaznacza opcję włączoną. Może też określić, czy system ma używać sond HTTP i HTTPS, czy tylko HTTP, co ma znaczenie przy specyficznych konfiguracjach zapór.

Jak działają niestandardowe karty Chrome podczas logowania?

Od Androida 12 logowanie do portali przechwytujących może odbywać się nie w prostym oknie WebView, ale w tzw. Custom Tabs, czyli niestandardowych kartach Chrome. To w pełni funkcjonalne okno przeglądarki otwierane bezpośrednio w przepływie logowania – użytkownik widzi znany interfejs, a system korzysta z tych samych mechanizmów bezpieczeństwa, co w zwykłej przeglądarce.

Dlaczego Custom Tabs są wygodniejsze?

Niestandardowe karty integrują logowanie z główną przeglądarką użytkownika. Dzięki temu dostępne jest autouzupełnianie loginów i danych płatniczych jednym kliknięciem, działa odtwarzanie treści chronionych DRM (np. Widevine) oraz zachowana jest spójność z konfiguracją zabezpieczeń, takich jak VPN czy prywatny DNS. Portal pozostaje aktywny w tle jako stały punkt dostępu przez cały czas trwania sesji, co jest ważne w bardziej rozbudowanych scenariuszach – na przykład w samolotach, gdzie portal obsługuje także płatne treści wideo.

Żeby włączyć przepływ z użyciem Custom Tabs, operator sieci musi obsłużyć Captive Portal API i w odpowiedzi JSON dodać atrybut x-android-use-custom-tabs z wartością 361335020. Ta liczba oznacza wersję modułu Mainline CaptivePortalLogin z aktualizacji ze stycznia 2026. Urządzenia z Androidem, które mają co najmniej tę wersję modułu, otworzą logowanie w niestandardowej karcie, zamiast w starszym oknie systemowym.

Jak bezpiecznie logować się do portalu przechwytującego?

Publiczne hotspoty z portalem przechwytującym są wygodne, ale bywają wykorzystywane w atakach. Cyberprzestępcy potrafią podszyć się pod hotelowe Wi‑Fi lub portal banku, a użytkownik widzi tylko znany formularz logowania. Jednym z przykładów jest złośliwe oprogramowanie Android/Spy.Agent.SI, które podszywa się pod Flash Playera, przejmuje uprawnienia administratora, a następnie wyświetla fałszywe ekrany logowania do aplikacji bankowych.

Po instalacji taki trojan sprawdza, czy na urządzeniu są zainstalowane aplikacje dużych banków, a gdy użytkownik próbuje się zalogować, pokazuje spreparowany formularz i blokuje ekran do czasu wpisania danych. Dane logowania trafiają na serwer atakującego, a złośliwy kod przechwytuje także wiadomości SMS z kodami autoryzującymi przelewy, co umożliwia kradzież pieniędzy z konta. W tym scenariuszu ofiara ma wrażenie, że loguje się do zaufanego portalu banku, choć w rzeczywistości formularz dostarcza malware.

Złośliwe aplikacje, takie jak Android/Spy.Agent.SI, potrafią wyświetlać fałszywe strony logowania i przechwytywać kody SMS, więc każda prośba o dane w nieoczekiwanym miejscu powinna od razu wzbudzić czujność.

Żeby ograniczyć ryzyko, warto trzymać się kilku zasad, gdy korzystasz z sieci z portalem przechwytującym:

• instaluj aplikacje wyłącznie z oficjalnych sklepów, nie z przypadkowych stron www,
• używaj mobilnego antywirusa, który wykrywa znane trojany bankowe,
• sprawdzaj adres strony logowania – bankowe serwisy otwieraj z własnej aplikacji lub zakładki, a nie z linku z portalu,
• wrażliwych operacji (bankowość, panele administracyjne) nie wykonuj w otwartych hotspotach, jeśli to możliwe,
• łącz się z VPN, gdy musisz pracować w publicznej sieci Wi‑Fi.

Jak skonfigurować portal przechwytujący w projektach WiFi4EU?

Program WiFi4EU wymaga, aby każda instalacja zgłoszona w sprawozdaniu miała własny portal uwierzytelniania z widocznym elementem identyfikacji wizualnej oraz osiągnęła co najmniej 10 użytkowników zalogowanych do sieci. W wielu wdrożeniach portal konfiguruje się w systemie cnMaestro wraz z punktami dostępowymi serii cnPilot serii E.

Jak wygląda konfiguracja portalu w cnMaestro?

Integrator po zalogowaniu do cnMaestro wybiera z menu „Guest Access Portal”, nadaje nazwę portalowi i ładuje plik z logiem – w projektach WiFi4EU zwykle używa się pliku wifi4eulogo.png, często łączonego z herbem gminy. Następnie ustawia kolor tła (np. przesuwając suwak w lewo, żeby uzyskać białe tło), wybiera język polski, zaznacza „WiFi4EU” oraz „Enable Self-test Modus”, który pozwala testować portal przed otrzymaniem właściwego identyfikatora sieci.

Na podstawie adresu IP (standardowo podaje się 0.0.0.0/0) oraz adresu URL portalu przechwytującego generowany jest Network UUID przez INEA. Ten identyfikator łączy fizyczną sieć z projektem w systemie Komisji Europejskiej i służy do zbierania danych pomiarowych. Po ustawieniu loga i podstawowych opcji integrator w zakładce „Content” dodaje polskie komunikaty, regulamin, warunki korzystania z sieci oraz adres w polu „On Success Redirect to URL”, czyli stronę, na którą użytkownik trafi po kliknięciu przycisku logowania.

Jak dodać snippet WiFi4EU i element identyfikacji wizualnej?

Instrukcje programu WiFi4EU opisują tzw. snippet JavaScript, który trzeba umieścić tuż po znaczniku <head> w kodzie portalu, aby zbierać dane pomiarowe. W cnMaestro snippet jest już wbudowany w mechanizm portalu, więc administrator nie musi ręcznie modyfikować HTML. Wystarczy przekazać poprawny adres IP i URL portalu, aby INEA mogła wygenerować UUID.

Osobnym wymogiem jest jednak element identyfikacji wizualnej na stronie – znacznik <img id="wifi4eubanner">. Snippet podmienia ten element na właściwe logo, ale tylko wtedy, gdy:

• ma on ustawioną szerokość i wysokość (np. przez CSS),
• znajduje się w widocznym obszarze strony,
• nie jest zakryty innymi elementami i nie ma obniżonej przezroczystości,
• jego identyfikator HTML dokładnie brzmi wifi4eubanner.

Jeśli w portalu brakuje tego znacznika, system monitorujący nie zobaczy logotypu WiFi4EU, a gmina dostanie powiadomienie o potencjalnym problemie technicznym – mimo że sama sieć działa poprawnie. W praktyce wystarczy dodać odpowiedni znacznik obrazka w szablonie portalu i dopilnować, żeby automatycznie ładowane logo było dobrze widoczne na wszystkich rozdzielczościach.

Jak spełnić warunek 10 użytkowników?

INEA uznaje projekt WiFi4EU za działający dopiero wtedy, gdy do portalu uwierzytelniającego zaloguje się co najmniej 10 różnych urządzeń klienckich. Oznacza to, że samo uruchomienie sieci i wyświetlenie loga nie wystarczy. W praktyce gminy organizują krótkie testy – proszą pracowników lub mieszkańców o podłączenie się do sieci, przejście przez portal i korzystanie z internetu przez jakiś czas. Dopiero po spełnieniu obu warunków (logo i 10 użytkowników) system może potwierdzić, że instalacja działa zgodnie z umową.

W projektach WiFi4EU działający portal przechwytujący oznacza nie tylko poprawne logowanie, ale także widoczne logo WiFi4EU i minimum 10 rzeczywistych urządzeń, które skorzystały z sieci.

Jak rozwiązywać problemy z portalem przechwytującym?

Typowe problemy z portalami przechwytującymi to brak automatycznego otwarcia strony logowania, komunikaty „Sieć niedostępna” lub błędne oznaczanie sieci jako offline. W ChromeOS i Androidzie często winna jest zapora, która blokuje sondy HTTP/HTTPS lub nie dopuszcza ruchu do określonych hostów weryfikacyjnych.

W środowiskach z kontrolą TLS/SSL administratorzy powinni zezwolić na nieprzefiltrowany dostęp do hostów używanych przez system do testowania łączności – w protokole HTTP na porcie 80, a w przypadku Captive Portal API także w HTTPS z prawidłowym certyfikatem. Jeśli certyfikat na API portalu jest nieprawidłowy lub samopodpisany, urządzenia wracają do starszego mechanizmu sond HTTP/HTTPS, co z kolei zwiększa ryzyko niespójnych wyników (np. HTTP działa, HTTPS nie).

W Androidzie logikę wykrywania portali i obsługi logowania utrzymuje aktualizowany moduł Network Stack, który zawiera m.in. usługi DhcpClient, IpClient, komponent NetworkMonitor oraz aplikację CaptivePortalLogin. Te elementy są dystrybuowane jako pakiet APK w ramach Mainline, więc nie można ich modyfikować bezpośrednio – dostosowanie zachowania osiąga się przez konfigurację sieci, a nie przez zmiany w systemie.

Gdy mimo poprawnej konfiguracji problem pozostaje, operatorzy sieci mogą analizować ruch DHCP (w tym opcję 114), odpowiedzi API, nagłówki HTTP i logi zapory. Często już proste logowanie żądań GET do interfejsu Captive Portal API pokazuje, czy urządzenia z Androidem faktycznie go wywołują, czy wracają do tradycyjnych sond, co ułatwia diagnozę.