Autouzupełnianie haseł w Androidzie ma nową klasę podatności — AutoFail wykrył krytyczne błędy w 9 menedżerach haseł i 5 popularnych przeglądarkach, które mogą przekazać dane logowania obcej domenie

Problem nie polega na tym, że menedżer haseł przechowuje login źle zaszyfrowany. Znacznie bardziej kłopotliwy jest moment, w którym Android ma zdecydować, do którego pola i której domeny wolno przekazać zapisane dane logowania. Badacze z TU Wien pokazali, że na tym etapie można zgubić informację o granicy między stronami, a wtedy poprawne hasło może trafić do formularza kontrolowanego przez inną domenę.

Badanie AutoFail: Breaking Web Boundaries using Android’s Autofill Framework, zaprezentowane na USENIX Security 2026, objęło 5 mobilnych przeglądarek i 9 menedżerów haseł. W 45 kombinacjach wykonano łącznie 450 testów, a każda z badanych przeglądarek i każdy z analizowanych menedżerów był dotknięty co najmniej jednym z wykrytych problemów. Autorzy wyróżnili sześć klas błędów bezpieczeństwa, w tym Cross-Site Credential Leakage, czyli sytuację, w której dane przeznaczone dla jednej strony mogą zostać wypełnione w polach należących do innego originu.

Problem powstaje między DOM-em strony, Androidem i menedżerem haseł

Na komputerze rozszerzenie menedżera haseł może bezpośrednio analizować strukturę strony. W Androidzie ścieżka jest bardziej złożona. Od Androida 8 system udostępnia Autofill Framework, który pośredniczy między aplikacją lub przeglądarką a usługą autouzupełniania.

Przeglądarka musi przetłumaczyć HTML i strukturę DOM strony na androidową strukturę AssistStructure z węzłami ViewStructure. Do menedżera haseł trafiają m.in. informacje o polach formularza, ich hierarchii oraz domenie zapisanej w polu webDomain. I właśnie tutaj zaczyna się problem: nie istnieje jeden rygorystyczny standard odwzorowania złożonej struktury strony WWW na strukturę wymaganą przez Androida.

To ma znaczenie szczególnie przy iframe, czyli sytuacji, w której jedna strona osadza treść pochodzącą z drugiej domeny. Strona banku może na przykład zawierać ramkę z systemu płatniczego, reklamowego albo antyfraudowego. Dla przeglądarki są to osobne konteksty bezpieczeństwa. Dla wadliwie przygotowanego mechanizmu autofill mogą jednak zacząć wyglądać jak jedna struktura.

Autorzy wskazali osiem problemów po stronie przeglądarek, m.in.:

• Excessive Scope – Firefox i Samsung Browser mogą przekazać usłudze autofill pola spoza aktualnie używanego kontekstu;

• Missing Autofill Validation – Firefox i Samsung Browser nie wykonywały końcowej kontroli, czy odpowiedź menedżera haseł trafia do właściwych pól;

• webDomain Omission – Samsung Browser, Phoenix i Brave nie zawsze przekazywały domenę formularza;

• Broken Hierarchy – Chrome, Firefox, Phoenix i Brave potrafiły utracić część relacji między zagnieżdżonymi dokumentami;

• HTTP Autofill Trigger – Samsung Browser i Firefox uruchamiały mechanizm autouzupełniania także na stronach HTTP;

• brak informacji o porcie, niejednoznaczne traktowanie ramek sandbox oraz brak pełnej informacji o credentialless.

Po stronie menedżerów haseł znaleziono z kolei cztery główne problemy. Bitwarden, Avira, RoboForm, 2FA Authenticator, LastPass i 1Password w określonych przypadkach wypełniały pola poza właściwym zakresem. Bitwarden, NordPass, Avira i RoboForm stosowały zbyt słabe heurystyki przypisywania formularza do domeny. Sześć produktów — Google Password Manager, Keeper, Bitwarden, 2FA Authenticator, Avira i RoboForm — podczas testów potrafiło proponować dane także dla HTTP bez ostrzeżenia. Wszystkie badane menedżery mogły natomiast w pewnych warunkach wypełniać dane w kontekście cross-site bez jednoznacznego ostrzeżenia użytkownika.

AutoFail objął Chrome, Firefoksa, Brave i największe menedżery haseł

Testy wykonano na fizycznym Google Pixel 6a z Androidem 16. Badacze uruchamiali 10 scenariuszy dla każdej pary przeglądarka–menedżer, ręcznie wywołując autofill i rejestrując cały przepływ danych. Pojedyncza interakcja trwała średnio około 5 sekund.

Sprawdzone przeglądarki to:

• Chrome 143.0.7499.192,

• Samsung Browser 29.0.1.12,

• Phoenix Browser 20.3.1.6275,

• Firefox 146.0.1,

• Brave 1.85.120.

W grupie menedżerów znalazły się:

• Google Password Manager,

• Keeper 17.3.30.144601,

• LastPass 6.36.0.17624,

• Bitwarden 2025.9.1,

• 2FA Authenticator 1.0.64,

• NordPass 5.4.4,

• 1Password 8.11.10,

• Avira 2.11,

• RoboForm 9.8.4.

Sześć kolejnych aplikacji — m.in. Dashlane, KeePass2Android, Norton i Enpass — początkowo zakwalifikowano do badań, ale wyłączono je z głównego eksperymentu, ponieważ wykrywały środowisko analityczne, zawieszały się albo w inny sposób uniemożliwiały powtarzalny pomiar. Nie oznacza to więc, że zostały uznane za odporne. Po prostu nie weszły do końcowego zestawu 45 badanych kombinacji.

Najgroźniejszy przypadek nazwano Cross-Site Credential Leakage — XSCL. Schemat ataku jest prosty do zrozumienia. Użytkownik widzi prawidłową stronę logowania domeny A, ale w jej strukturze znajduje się zawartość domeny B. Jeżeli przeglądarka przekaże zbyt szeroką strukturę, a menedżer haseł potraktuje wszystkie pola jak należące do właściwej strony, login i hasło mogą zostać wpisane również w niewidocznym formularzu kontrolowanym przez B.

Możliwa jest też sytuacja odwrotna. Atakująca witryna może osadzić prawidłową stronę logowania w iframe, a obok umieścić niewidoczne pola. Użytkownik widzi autentyczny formularz i sam wybiera z listy zapisane konto, lecz część danych trafia poza właściwy kontekst.

To ważne rozróżnienie: AutoFail nie opisuje wyłącznie „automatycznego wpisania hasła bez kliknięcia”. W części scenariuszy użytkownik normalnie dotyka propozycji menedżera haseł, a błąd polega na tym, że system wcześniej nieprawidłowo ustalił, do czego odnosi się ta zgoda.

Badacze pokazali taki atak na rzeczywistych serwisach. W przypadku Kick wykorzystano niewidoczny, mierzący 1 × 1 piksel iframe ładowany z infrastruktury Stripe. W konfiguracji testowej z Firefox Nightly i RoboForm zapisane dane dla Kick zostały po zaakceptowaniu autofill przekazane do przygotowanego przez badaczy kodu eksfiltrującego. Osobne demonstracje wykonano również dla AOL i Internet Archive.

To nie jest wyłącznie laboratoryjny przypadek — część warunków występuje masowo w sieci

Najmocniejszą częścią AutoFail nie jest samo stworzenie proof-of-conceptu, lecz sprawdzenie, jak często potrzebne elementy rzeczywiście występują na normalnych stronach.

Badacze przeanalizowali dane HTTP Archive oparte na zestawie CrUX Top 1 Million. Z 822 439 skutecznie przeanalizowanych stron 485 470, czyli 59,0 proc., można było osadzić cross-origin, ponieważ nie miały wystarczających zabezpieczeń X-Frame-Options lub CSP frame-ancestors. Zabezpieczenia przed takim osadzaniem stosowało 41,0 proc. próby. Dane pochodziły z migawki z 1 maja 2026 r.

Osobny crawler odwiedził 3 522 z próby 4 000 stron i znalazł 9 552 iframe, z czego 3 682 pochodziły z innej witryny niż dokument nadrzędny. 2 167 ramek używało sandbox, ale aż 1 789 z nich — 82,6 proc. — jednocześnie zezwalało na allow-same-origin i allow-scripts. W analizowanym modelu zagrożenia takie połączenie niwelowało istotną część ochrony oferowanej przez sandbox.

Jeszcze bardziej praktyczna liczba dotyczy serwisów z formularzem hasła. Takie pole wykryto na 412 stronach. 160 z nich, czyli 38,8 proc., miało równocześnie cross-site iframe spełniający strukturalne warunki potrzebne do ataku XSCL w modelu „gadget attacker”. Z kolei 826 stron, czyli 23,5 proc. całej skutecznie przebadanej próby, spełniało warunki strukturalne do Cross-Site Suggestions. To nie znaczy, że 38,8 proc. serwisów logowania da się dziś automatycznie okraść. Badanie nie sprawdzało, czy napastnik rzeczywiście może przejąć treść każdej znalezionej ramki. Pokazuje jednak, że architektura stron potrzebna do ataku nie jest egzotycznym wyjątkiem.

ANCHOR

Jest jeszcze drugi wektor, który nie wymaga kradzieży samego hasła. Cross-Context Account Oracle pozwala aplikacji działającej na Androidzie sprawdzać, czy użytkownik prawdopodobnie ma zapisane dane logowania do wybranego serwisu. Atak wykorzystuje różnice w wymiarach okna z propozycjami autofill. Aplikacja podstawia wskazaną domenę do struktury żądania, wywołuje mechanizm autouzupełniania i porównuje geometrię odpowiedzi z przypadkiem domeny bez zapisanych danych.

Spośród 13 menedżerów, które dało się sprawdzić w tym dodatkowym teście, trzy były podatne. Konsekwencją nie musi być przejęcie konta. Sam fakt posiadania konta może ujawniać wrażliwą informację — np. korzystanie z określonego portalu medycznego, politycznego lub randkowego. Android Security zakwalifikował zgłoszenie tego problemu jako High Severity, a w maju 2026 r. wypłacił badaczom 7 000 dolarów nagrody.

Nie należy jednak z tego wyciągać wniosku „usuń menedżer haseł”. To byłaby zła decyzja. Unikalne, losowe hasła zapisane w menedżerze nadal chronią przed znacznie częstszym problemem — ponownym użyciem tego samego hasła i skutkami wycieku z jednej usługi. Trzeba ograniczyć konkretną powierzchnię ataku: automatyczne przekazywanie poświadczeń w niejednoznacznym kontekście strony.

Stan poprawek również nie jest jednolity. Autorzy zgłaszali problemy producentom przeglądarek od września 2025 do lutego 2026 r. Chrome i Firefox potwierdziły błędy i rozpoczęły prace nad rozwiązaniami. Brave skierował część problemu do projektu Chromium, Samsung również wskazywał na poprawki po stronie Google, natomiast na odpowiedź Phoenix badacze czekali jeszcze w kwietniu 2026 r.

Wśród menedżerów Bitwarden, Keeper i NordPass wdrożyły częściowe poprawki, 1Password pracował m.in. nad Cross-Site Context Concealment, a Avira przygotowywała własne mitygacje. Część problemów LastPass, 1Password i Bitwarden została skierowana do zespołów przeglądarek lub Androida, ponieważ nie da się ich poprawnie usunąć wyłącznie zmianą logiki w aplikacji menedżera. 2FA Authenticator i RoboForm nie odpowiedziały badaczom przed zamknięciem opisanego procesu disclosure. W późniejszych testach terenowych RoboForm był jedynym menedżerem, dla którego badacze nadal dysponowali działającą niezałataną wersją umożliwiającą demonstracje.

FAQ

Czy trzeba przestać używać menedżera haseł na Androidzie?
Nie. Rezygnacja z menedżera zwykle zwiększa ryzyko używania słabych lub powtarzanych haseł. Priorytetem jest aktualizacja aplikacji i przeglądarki oraz ograniczenie automatycznego wypełniania w sytuacjach, w których nie kontrolujemy dokładnie domeny.

Czy samo wejście na złośliwą stronę wystarczy do kradzieży hasła?
Nie w każdym scenariuszu. Część ataków wymaga konkretnej struktury iframe, odpowiedniej konfiguracji strony oraz podatnej pary przeglądarka–menedżer. W wielu wariantach użytkownik musi też zaakceptować propozycję autofill. XSCL jest niebezpieczny dlatego, że ta zgoda może dotyczyć pozornie prawidłowego formularza, podczas gdy dane zostają wypełnione także w innym kontekście.

Czy wyłączenie autouzupełniania całkowicie usuwa problem?
Usuwa podstawową ścieżkę wielu ataków opisanych w AutoFail, ale kosztem wygody. Nie rozwiązuje też wszystkich problemów związanych z samym Android Autofill Framework. Jeżeli menedżer umożliwia ręczne wywoływanie wypełnienia dopiero po sprawdzeniu domeny, jest to rozsądniejszy kompromis niż bezwarunkowe autofill.

Co z logowaniem przez HTTP?
Nie należy wprowadzać poświadczeń na stronie logowania działającej po zwykłym HTTP. W testach sześć menedżerów proponowało zapisane dane na takich stronach bez ostrzeżenia, gdy żądanie autofill zostało uruchomione przez kompatybilną przeglądarkę. Chrome, Brave i Phoenix w badanej konfiguracji w ogóle nie uruchamiały autofill na HTTP, natomiast Firefox i Samsung Browser przekazywały takie żądania dalej.

Czy passkey chroni przed AutoFail?
AutoFail koncentrował się na danych uwierzytelniających przekazywanych przez Autofill Framework i nie stanowi pełnej analizy bezpieczeństwa passkeys. Jeżeli dany serwis poprawnie obsługuje passkey, przejście z wpisywanego hasła na kryptograficzne uwierzytelnienie eliminuje konieczność przekazania temu formularzowi klasycznego hasła, ale nie należy traktować tego badania jako dowodu odporności każdego mechanizmu passkey na wszystkie ataki interfejsu lub przeglądarki.

Co użytkownik Androida powinien sprawdzić teraz?
Najpierw wersję przeglądarki i menedżera haseł w Google Play, następnie ustawienia autofill i auto-lock. Auto-lock ma dodatkowe znaczenie przy Cross-Context Account Oracle, ponieważ zablokowany sejf ogranicza możliwość wykorzystania opisanego kanału bocznego. Przy logowaniu do banku, poczty, konta Google, Microsoftu lub administratora firmowego nie należy akceptować propozycji danych, jeśli formularz pojawia się w osadzonej stronie, nietypowym oknie lub po przekierowaniu, którego domeny nie da się jednoznacznie sprawdzić.

Od czego zacząć?
Od aktualizacji obu elementów pary, nie tylko menedżera haseł: przeglądarki i usługi autofill. Następnie wyłącz automatyczne uzupełnianie bez interakcji, jeżeli Twój menedżer je oferuje, włącz automatyczne blokowanie sejfu i sprawdź, czy najważniejsze konta można przełączyć na passkey. Najgorszy błąd do usunięcia w pierwszej kolejności to bezrefleksyjne zatwierdzanie propozycji hasła tylko dlatego, że menedżer je pokazał — po AutoFail sama obecność właściwego loginu na liście nie jest wystarczającym dowodem, że formularz należy do właściwej domeny.