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

Logowanie do portalu przechwytującego to specjalny etap autoryzacji w publicznej sieci Wi‑Fi, który pojawia się przed uzyskaniem pełnego dostępu do internetu. W praktyce widzisz go jako stronę logowania lub akceptacji regulaminu, która wyskakuje zaraz po połączeniu z siecią na lotnisku, w hotelu czy miejskim hotspotcie. Taki mechanizm działa według ściśle określonych reguł sieciowych i – jeśli jest źle skonfigurowany – potrafi mocno utrudnić życie użytkownikom. Więcej o tym, jak to działa technicznie, jakie ma wymagania (np. w projektach WiFi4EU) i jak to skonfigurować bezpiecznie, znajdziesz w tym artykule.

Czym jest portal przechwytujący?

Portal przechwytujący to warstwa pośrednia między urządzeniem użytkownika a internetem. Po połączeniu z siecią Wi‑Fi ruch użytkownika jest na początku blokowany lub przekierowywany, a pierwsze zapytanie HTTP/HTTPS trafia na specjalną stronę logowania. Dopiero po zalogowaniu, akceptacji regulaminu lub dokonaniu płatności zapora sieciowa otwiera dostęp do reszty sieci.

Stosują go głównie miejsca publiczne – lotniska, hotele, galerie handlowe, miejskie hotspoty – aby wymusić akceptację warunków korzystania, pokazać informacje o miejscu albo zliczyć aktywnych użytkowników. W projektach dotacyjnych, takich jak WiFi4EU, portal pełni dodatkowo funkcję dowodową: musi wyświetlać wymagany baner oraz obsłużyć co najmniej 10 unikalnych urządzeń, aby instalacja została uznana za działającą.

Portal przechwytujący to nie „błąd internetu”, tylko zaplanowany element infrastruktury Wi‑Fi, który decyduje, czy użytkownik ma już pełne połączenie, czy dopiero przechodzi proces logowania.

Jak działa logowanie do portalu przechwytującego?

Mechanizm logowania opiera się na kontroli ruchu IP w bramie sieciowej lub kontrolerze Wi‑Fi. Przy pierwszym połączeniu urządzenie otrzymuje adres z DHCP, ale jego ruch jest filtrowany – zwykle tylko do kilku adresów docelowych, w tym samej strony logowania. Gdy użytkownik potwierdzi warunki lub poda dane, kontroler zmienia reguły dla danego adresu MAC lub adresu IP i zezwala na normalny ruch.

Wykrywanie portalu w ChromeOS

Na urządzeniach z ChromeOS w firmach i szkołach wykrywanie portalu logowania można włączyć lub wyłączyć w konsoli administracyjnej Google. W sieciach zarządzanych jest ono domyślnie wyłączone, bo zapory i serwery proxy potrafią zaburzać automatyczne sondowanie, co kończy się np. komunikatem, że sieć jest offline. Administrator może jednak dla wybranej sieci (np. gościnnej) włączyć mechanizm „login required”, dzięki czemu system sam otworzy stronę logowania w przeglądarce.

Gdy wykrywanie jest aktywne i urządzenie połączy się z siecią chronioną przez portal, ChromeOS wyświetla powiadomienie z informacją, że trzeba się zalogować, a następnie automatycznie otwiera stronę portalu. Jeżeli wykrywanie pozostanie wyłączone, użytkownik musi sam uruchomić przeglądarkę i wejść na dowolny adres HTTP, aby portal go przechwycił – wielu użytkowników błędnie uznaje wtedy, że „Wi‑Fi nie działa”.

Jak włączyć wykrywanie portalu przechwytującego w ChromeOS?

Administrator może skonfigurować wykrywanie portalu dla konkretnego profilu sieci Wi‑Fi z poziomu konsoli Google. Po zapisaniu zmian konfiguracja jest wysyłana na wszystkie zarządzane urządzenia z ChromeOS. W ustawieniach sieci pojawia się sekcja „Ustawienia portalu przechwytującego”, gdzie można zdecydować, czy urządzenie ma wykonywać sondy HTTP/HTTPS, czy tylko HTTP.

Jak Android wykrywa portal przechwytujący?

Od Androida 5.0 system sam próbuje rozpoznać, czy sieć wymaga logowania. Wysyła krótkie zapytania HTTP lub HTTPS do znanych serwerów kontrolnych (np. connectivitycheck.gstatic.com) i analizuje odpowiedź. Jeśli zamiast spodziewanego niewielkiego pliku otrzyma przekierowanie HTTP, uznaje, że stoi za Captive Portal i wyświetla stronę logowania.

RFC7710bis i opcja DHCP 114

Tradycyjne sondy HTTP bywają zawodne: część sieci je przepuszcza, inne filtrują, nie ma też jednego standardowego adresu, do którego powinny trafiać. Dlatego nowsze systemy, jak Android 11, wspierają mechanizm opisany w RFC7710bis. W tym standardzie serwer DHCP może wysłać do klienta opcję 114 – adres URL interfejsu opisującego status portalu. Gdy telefon uzyska taki URL, pobiera plik JSON i na jego podstawie wie, czy konieczne jest logowanie, jaki adres logowania użyć oraz jakie są limity czasu lub danych.

Captive Portal API i format JSON

Nad warstwą DHCP powstał wyspecjalizowany Captive Portal API, opisany w RFC 8908. To interfejs, z którego korzysta Android, aby niezawodnie stwierdzić, czy użytkownik jest za portalem, a jeśli tak – jaki jest adres strony logowania, ile czasu pozostało w sesji oraz gdzie znajduje się punkt dostępu. API posługuje się prostym JSON-em z polami takimi jak:

• captive – informacja, czy wymagane jest uwierzytelnianie,
• 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 – pozostały czas sesji w sekundach,
• x-android-use-custom-tabs – numer wersji modułu Captive Portal Login (np. 361335020 dla wydania ze stycznia 2026 r.), który mówi, że portal może być otwarty w niestandardowej karcie Chrome.

Jeśli pole captive ma wartość true, urządzenie natychmiast wyświetla stronę logowania, omijając standardowe sondy. Gdy wartość jest false, Android sprawdza jeszcze sondy HTTP/HTTPS, zanim uzna, że ma pełny dostęp do internetu.

Rola modułu Network Stack

Na współczesnych urządzeniach Android logiką wykrywania i obsługi portali zarządza moduł Network Stack. To aktualizowany przez Google komponent typu Mainline, który zawiera m.in. usługę NetworkMonitor, klienta DHCP oraz aplikację logowania do portalu (com.google.android.captiveportallogin). Dzięki temu poprawki do wykrywania captive portal, obsługi Captive Portal API czy nowych typów pakietów mogą trafiać na urządzenia przez Google Play System Update, bez czekania na aktualizację pełnego systemu.

Network Stack – jako moduł Mainline – pozwala Androidowi w 2026 r. szybko nadążać za zmianami w standardach, takimi jak RFC 8908 czy nowe opcje DHCP, co ogranicza problemy z błędnym wykrywaniem portali przechwytujących.

Jak skonfigurować portal przechwytujący dla WiFi4EU?

Program WiFi4EU stawia bardzo konkretne wymagania wobec portali autoryzacji. Portal musi nie tylko poprawnie logować użytkowników, ale też zawierać element identyfikacji wizualnej (baner) oraz fragment kodu – tzw. snippet – który mierzy użycie sieci. W praktyce oznacza to dostosowanie strony logowania zgodnie z wytycznymi Komisji Europejskiej.

Jak działa snippet WiFi4EU?

W dokumentacji WiFi4EU znajdziesz fragment kodu JavaScript, który trzeba umieścić w sekcji <head> strony portalu – tuż po znaczniku otwierającym. Fragment deklaruje trzy zmienne: czas startu, identyfikator sieci (Network UUID) oraz język portalu. Następnie ładowany jest zewnętrzny plik wifi4eu.min.js z domeny Komisji Europejskiej. Ten skrypt odpowiada za pomiar ruchu oraz wstawienie banera na podstawie ustawionego języka.

W niektórych rozwiązaniach – jak cnMaestro – snippet jest już zaszyty w oprogramowaniu portalu. Administrator musi wtedy jedynie podać adres portalu i zakres adresów IP (często 0.0.0.0/0) w systemie WiFi4EU, aby otrzymać Network UUID. Bez tego identyfikatora Komisja nie powiąże ruchu z konkretną siecią gminy.

Instalacja elementu identyfikacji wizualnej WiFi4EU

Sam snippet nie wystarczy. Na stronie należy umieścić znacznik HTML, który stanie się miejscem dla banera WiFi4EU. Wymagane jest, aby element miał identyfikator wifi4eubanner, pierwotnie określone wymiary, był widoczny i nie zasłonięty innymi elementami. Minimalny kod to:

Aby portal spełniał wymogi WiFi4EU, na stronie logowania trzeba umieścić element tak, by po załadowaniu strony był od razu widoczny dla użytkownika.

Rozmiar i położenie banera określasz w CSS. Dla ekranów węższych niż 600 px grafika powinna zajmować co najmniej 90% szerokości okna, a dla szerszych – co najmniej 50%. Dzięki temu znak WiFi4EU jest wyraźnie widoczny zarówno na smartfonie, jak i na laptopie.

Warunek 10 urządzeń w WiFi4EU

INEA (obecnie HADEA) uznaje instalację WiFi4EU za działającą, gdy portal autoryzacji spełnia dwie przesłanki: wyświetla baner WiFi4EU oraz zalogowało się przez niego przynajmniej 10 różnych urządzeń klienckich. Jeśli snippet lub baner są źle umieszczone, system nie zlicza poprawnie sesji i gmina otrzymuje powiadomienie o „potencjalnym problemie technicznym”. Stąd tak duży nacisk na ścisłe trzymanie się instrukcji – od sekcji <head> po atrybuty CSS.

Jak użytkownik widzi logowanie do portalu?

Od strony użytkownika logowanie do portalu wygląda prosto: po połączeniu z Wi‑Fi pojawia się powiadomienie o konieczności zalogowania, po jego kliknięciu otwiera się strona logowania. Pod spodem działa jednak dość rozbudowana maszyneria – od opcji DHCP, przez Captive Portal API, po wyspecjalizowaną aplikację logowania w systemie.

Niestandardowe karty Chrome na Androidzie

Na Androidzie 12 i nowszych logowanie może odbywać się w tzw. niestandardowych kartach Chrome. To tryb, w którym system otwiera portal przechwytujący w środowisku głównej przeglądarki, a nie w prostym oknie WebView. Dzięki temu użytkownik ma do dyspozycji autouzupełnianie haseł i płatności, obsługę treści chronionych DRM, integrację z VPN i prywatnym DNS oraz spójny interfejs z resztą przeglądarki.

Aby sieć mogła używać niestandardowych kart, jej portal musi obsługiwać Captive Portal API i w odpowiedzi JSON umieścić parametr x-android-use-custom-tabs z numerem aktualnej wersji modułu Captive Portal Login (np. 361335020 dla wydania ze stycznia 2026 r.). Wtedy urządzenia z uaktualnionym modułem automatycznie wybiorą lepszy scenariusz logowania.

Jak wygląda przepływ od wykrycia do połączenia?

Po stronie Androida ścieżka jest prosta: najpierw NetworkMonitor sprawdza, czy istnieje opcja DHCP 114 z adresem API. Jeśli tak, wysyła żądanie GET i analizuje JSON. Gdy pole captive ma wartość true, natychmiast otwiera aplikację logowania – w zwykłym oknie lub w karcie przeglądarki, zależnie od konfiguracji. Jeśli wartość jest false, przechodzi w standardowy tryb sprawdzania łączności za pomocą sond HTTP/HTTPS, żeby nie uruchamiać logowania, gdy sieć jest już w pełni otwarta.

Jakie zagrożenia wiążą się z fałszywymi stronami logowania?

Portale przechwytujące są naturalnym elementem infrastruktury, ale cyberprzestępcy chętnie naśladują ich zachowanie. Na Androidzie głośnym przykładem był szkodliwy program wykrywany jako Android/Spy.Agent.SI. Podszywał się pod Flash Player, po zainstalowaniu uzyskiwał uprawnienia administratora, a potem sprawdzał, które aplikacje bankowe znajdują się na urządzeniu.

Gdy ofiara uruchamiała aplikację banku, złośliwe oprogramowanie wyświetlało fałszywą stronę logowania i blokowało ekran tak długo, aż użytkownik wpisał login i hasło. Dane trafiały bezpośrednio do operatorów ataku, a z uwagi na przechwytywanie SMS z kodami autoryzującymi możliwe było także potwierdzanie przelewów bez wiedzy właściciela konta. Mechanizm wizualnie przypominał klasyczny portal przechwytujący, ale działał w ramach zainfekowanej aplikacji, a nie infrastruktury sieciowej.

Fałszywe „portale logowania” w aplikacjach mobilnych – takich jak kampanie Android/Spy.Agent.SI – potrafią przechwytywać nie tylko hasła, ale też SMS-y autoryzujące, co bezpośrednio przekłada się na utratę środków z kont bankowych.

Podstawowa ochrona polega na instalowaniu aplikacji wyłącznie z oficjalnych sklepów, odrzucaniu próśb o uprawnienia administratora przez programy o niejasnym pochodzeniu oraz używaniu w telefonie aktualnego oprogramowania antywirusowego. W realnym portalu przechwytującym logowanie zawsze odbywa się w przeglądarce – pojawia się pasek adresu i certyfikat HTTPS – a nie wewnątrz dowolnej aplikacji, która nagle domaga się „ponownego logowania do banku”.