spoofing w zewnętrznych formularzach

Spoofing w zewnętrznych formularzach wykorzystuje zaufaną domenę usługi do hostowania fałszywej treści.

Jak działa spoofing w zewnętrznym formularzu

Spoofing w zewnętrznych formularzach polega na takim przedstawieniu formularza, aby użytkownik uznał go za element znanej witryny, mimo że dane są zbierane przez inny system albo treść została podmieniona. Charakterystyczny przypadek występuje wtedy, gdy zaufana domena udostępnia miejsce na formularz, stronę osadzoną w ramce <iframe>, przekierowanie lub zasób generowany przez system publikacji treści. Atakujący może wykorzystać tę funkcję do umieszczenia komunikatu imitującego panel logowania, płatność, ankietę albo formularz kontaktowy.

Sam fakt wyświetlenia adresu zaczynającego się od https:// nie potwierdza, że formularz jest prawdziwy. HTTPS szyfruje połączenie z serwerem i pozwala zweryfikować certyfikat dla danej domeny, ale nie ocenia, czy właściciel podstrony opublikował uczciwą treść. Jeżeli fałszywy formularz znajduje się na prawidłowo działającej domenie, przeglądarka może pokazywać poprawną kłódkę, a użytkownik nadal może wpisywać dane do elementu kontrolowanego przez obcy serwer.

Ślady techniczne widoczne w kodzie i adresie

Weryfikacja formularza zaczyna się od sprawdzenia jego właściwości w narzędziach deweloperskich przeglądarki. Element <form> ma atrybut action, wskazujący adres, na który przeglądarka wysyła dane po zatwierdzeniu. Jeżeli strona znajduje się pod domeną firmy, lecz action prowadzi do innej domeny, krótkiego adresu przekierowującego albo nieznanego endpointu, jest to sygnał wymagający wyjaśnienia. Wysyłanie metodą POST nie oznacza automatycznie bezpieczeństwa, ponieważ metoda HTTP opisuje sposób transportu, a nie wiarygodność odbiorcy.

Niebezpieczna treść może być także umieszczona w ramce. Wtedy adres widoczny na pasku przeglądarki należy do strony nadrzędnej, natomiast formularz jest pobierany z adresu określonego w atrybucie src elementu <iframe>. Różnica między domeną nadrzędną a domeną ramki powinna być traktowana ostrożnie, zwłaszcza gdy formularz prosi o hasło, kod jednorazowy, numer karty lub dane logowania. Pomocne są również informacje z zakładki Network: można sprawdzić nazwę hosta, metodę żądania, kod odpowiedzi HTTP oraz zasoby JavaScript modyfikujące zawartość formularza.

Warto odróżnić domenę od subdomeny i podobnie wyglądających nazw. Adres logowanie.example.com jest subdomeną example.com, natomiast example.com.logowanie.net należy do domeny logowanie.net. Znaki Unicode mogą tworzyć nazwy wizualnie podobne do łacińskich, a skrócone adresy ukrywają właściwy cel przekierowania. Sama obecność logo, kolorów i nazwy organizacji nie jest dowodem autentyczności, ponieważ te elementy można skopiować w zwykłym kodzie HTML i CSS.

Wykorzystanie zaufanej domeny przez atakującego

Źródłem problemu może być przejęte konto redakcyjne, luka w systemie CMS, nieprawidłowo zabezpieczony moduł ankietowy albo funkcja pozwalająca użytkownikom publikować własne treści. Jeżeli serwer przyjmuje kod HTML bez odpowiedniego filtrowania, możliwe jest wstrzyknięcie elementów formularza lub skryptu. W przypadku podatności XSS złośliwy kod JavaScript może zmienić tekst nagłówka, podmienić przyciski, przechwycić wartości pól albo dodać przekierowanie. Ryzyko zależy od zakresu podatności oraz od tego, czy skrypt działa w kontekście zaufanej witryny.

Ochrona serwisu powinna obejmować ograniczenie możliwości publikowania formularzy, filtrowanie dozwolonych znaczników, kontrolę atrybutów takich jak action, src i href oraz zasadę najmniejszych uprawnień dla kont administracyjnych. Nagłówki bezpieczeństwa mogą ograniczyć skutki błędnej konfiguracji. Content-Security-Policy pozwala określać dozwolone źródła skryptów, ramek i połączeń, a dyrektywa form-action może ograniczyć adresy, do których formularze mogą wysyłać dane. Dla ramek z innych domen stosuje się także frame-ancestors lub nagłówek X-Frame-Options, zależnie od potrzeb i obsługi przeglądarek.

Ważne jest rejestrowanie zmian w treści oraz szybkie unieważnianie przejętych sesji i tokenów. Administrator powinien porównać kod podejrzanej podstrony z wersją przechowywaną w repozytorium lub kopii zapasowej, przejrzeć historię logowania i sprawdzić, czy formularz wysyła dane do nieautoryzowanego hosta. Przy analizie nie należy wpisywać prawdziwych haseł do podejrzanego formularza. Jeżeli dane zostały już wysłane, hasło trzeba zmienić na oficjalnej stronie usługi, a używane ponownie hasła również wymienić.

Bezpieczne postępowanie na laptopie i komputerze

Użytkownik może ograniczyć ryzyko, otwierając usługę przez ręcznie wpisany lub wcześniej zapisany adres, zamiast przez link z wiadomości. Przed wysłaniem formularza należy sprawdzić pełny adres strony, domenę dokumentu oraz ewentualne przekierowania. Nietypowa prośba o ponowne podanie hasła, kodu MFA, numeru karty lub klucza odzyskiwania powinna skłonić do przerwania operacji i niezależnego wejścia do aplikacji. Menedżer haseł często nie uzupełni danych na domenie innej niż zapisana, co może ujawnić różnicę między prawdziwym serwisem a imitacją.

Po podejrzeniu spoofingu warto zamknąć kartę, usunąć wpisane dane z formularza i przeskanować urządzenie aktualnym programem ochronnym. Jeżeli formularz pobrał plik, nie należy go uruchamiać przed sprawdzeniem rozszerzenia, podpisu i źródła. W przeglądarce można przejrzeć uprawnienia witryny, dane zapisane dla domeny oraz ostatnio pobrane pliki. Zmiana hasła powinna odbywać się na właściwej stronie, najlepiej po unieważnieniu aktywnych sesji; włączone uwierzytelnianie wieloskładnikowe zmniejsza skutki kradzieży samego hasła, ale nie zastępuje ostrożności.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego podczas przyjęcia urządzenia można opisać objawy takie jak samoczynne przekierowania, nowe rozszerzenia przeglądarki, zmieniona strona startowa lub pojawiające się formularze o nietypowej treści. Przy diagnostyce sprawdza się między innymi zainstalowane dodatki, ustawienia przeglądarki, procesy uruchamiane wraz z systemem i ślady pobranych plików, bez uznawania pojedynczego komunikatu lub ikony kłódki za rozstrzygający dowód bezpieczeństwa.