brak filtrowania treści w polach formularzy

Brak filtrowania treści w polach formularzy to luka bezpieczeństwa umożliwiająca wprowadzenie potencjalnie złośliwych danych.

Brak filtrowania treści w polach formularzy – czym jest problem

Brak filtrowania treści w polach formularzy oznacza sytuację, w której aplikacja przyjmuje dane od użytkownika bez dostatecznego sprawdzenia ich rodzaju, długości, struktury i przeznaczenia. Formularzem może być pole logowania, wyszukiwarka, komentarz, formularz kontaktowy, rejestracja konta, koszyk zakupowy albo panel umożliwiający przesłanie pliku. Sam fakt, że dane zostały wpisane w przeglądarce, nie oznacza, że są bezpieczne. Każda treść pochodząca od użytkownika powinna być traktowana jako niepewna aż do momentu przeprowadzenia odpowiedniej kontroli po stronie aplikacji.

Ryzyko pojawia się wtedy, gdy wpisany tekst zostaje wyświetlony innym osobom, zapisany w bazie danych, użyty w zapytaniu, przekazany do innego modułu lub dołączony do wiadomości generowanej przez system. Niebezpieczna zawartość może wyglądać jak zwykły tekst, ale po osadzeniu w określonym miejscu może zmienić sposób działania strony. W konsekwencji możliwe jest naruszenie poufności danych, przejęcie sesji użytkownika, zmiana zawartości widoku, utrudnienie działania aplikacji albo wykonanie operacji, której osoba korzystająca z systemu nie zamierzała uruchamiać.

Nie należy utożsamiać filtrowania wyłącznie z usuwaniem pojedynczych znaków. Skuteczna ochrona wymaga połączenia kilku mechanizmów: określenia dozwolonego formatu danych, walidacji wartości, bezpiecznego zapisywania, właściwego kodowania przy wyświetlaniu oraz kontroli uprawnień. Jeżeli aplikacja przyjmuje nazwisko, można oczekiwać krótkiego tekstu o przewidywalnej strukturze. Jeżeli przyjmuje opis problemu, zakres dozwolonych znaków będzie szerszy, ale nadal powinny obowiązywać limity długości i bezpieczny sposób prezentacji.

Filtrowanie treści a walidacja danych wejściowych

Filtrowanie treści i walidacja danych wejściowych są ze sobą związane, lecz nie oznaczają tego samego. Walidacja odpowiada na pytanie, czy wartość spełnia reguły biznesowe i techniczne. Przykładowo można sprawdzić, czy pole wymagane nie jest puste, czy adres poczty ma oczekiwaną strukturę, czy identyfikator składa się z dozwolonych znaków, a przesłany dokument ma właściwy typ i rozmiar. Filtrowanie bywa używane jako dodatkowa kontrola, jednak samo usuwanie podejrzanych fragmentów nie daje pewności, że pozostała treść jest bezpieczna.

Istotne jest rozróżnienie walidacji wykonywanej w przeglądarce od walidacji wykonywanej na serwerze. Kontrola w interfejsie poprawia wygodę korzystania z formularza i pozwala szybko wskazać błąd, ale może zostać pominięta lub zmieniona. Z tego powodu decydujące sprawdzenie powinno odbywać się po stronie serwera, przed zapisaniem danych albo uruchomieniem operacji. Dodatkowo komunikaty o błędach powinny być sformułowane tak, aby nie ujawniały szczegółów implementacji, struktury zapytań, nazw tabel ani informacji pomocnych przy obchodzeniu zabezpieczeń.

Ważną zasadą jest stosowanie listy dozwolonych wartości tam, gdzie jest to możliwe. Dla wyboru rodzaju urządzenia, statusu zgłoszenia czy formy kontaktu bezpieczniej zaakceptować wyłącznie wartości z ustalonego zbioru niż próbować rozpoznawać wszystkie możliwe odmiany błędnego wpisu. W polach opisowych potrzebne jest natomiast ograniczenie długości, kontrola kodowania znaków i bezpieczne wyświetlanie. Reguły powinny odpowiadać rzeczywistemu zastosowaniu pola, ponieważ zbyt szerokie dopuszczanie danych zwiększa ryzyko, a zbyt restrykcyjna kontrola może utrudniać poprawne korzystanie z formularza.

Pola formularzy i typowe skutki braku kontroli

Jednym z częstszych skutków braku filtrowania jest wstrzyknięcie treści do strony wyświetlanej w przeglądarce. Może do tego dojść w komentarzach, wynikach wyszukiwania, nazwach profili, opisach zgłoszeń lub komunikatach generowanych na podstawie wpisanej wartości. Jeżeli aplikacja potraktuje taki wpis jako część kodu widoku, osoba odwiedzająca stronę może zobaczyć zmienioną treść, zostać przekierowana albo wykonać działanie w niezamierzony sposób. Zagrożenie dotyczy nie tylko autora wpisu, lecz także innych osób, które później otworzą zapisany materiał.

Inny rodzaj problemu powstaje wtedy, gdy dane z formularza są łączone z zapytaniami do bazy danych bez bezpiecznego wiązania parametrów. Wpis niezgodny z oczekiwanym formatem może wpłynąć na interpretację zapytania, ujawnić fragment danych, zmienić wynik wyszukiwania albo zakłócić działanie aplikacji. Właściwą ochroną jest używanie parametryzowanych zapytań, rozdzielenie danych od instrukcji oraz ograniczenie uprawnień konta, z którego aplikacja korzysta przy komunikacji z bazą.

Niebezpieczeństwo może dotyczyć także przesyłanych plików. Samo sprawdzenie rozszerzenia nie wystarcza, ponieważ nazwa pliku może zostać zmieniona, a zawartość może nie odpowiadać deklarowanemu typowi. Kontrola powinna obejmować rozmiar, format, sposób przechowywania, nazwę nadawaną po stronie serwera oraz możliwość późniejszego wykonania pliku. W zależności od zastosowania przydatne jest przechowywanie załączników poza publicznym obszarem witryny i udostępnianie ich przez mechanizm, który wcześniej sprawdza uprawnienia.

Brak filtrowania może prowadzić również do problemów mniej widocznych dla osoby korzystającej z formularza. Zbyt długi wpis może obciążać aplikację, nietypowe znaki mogą powodować błędy kodowania, a nieprawidłowe dane mogą zostać przeniesione do poczty elektronicznej, raportu lub systemu obsługi zgłoszeń. W takim łańcuchu każdy kolejny moduł powinien traktować przekazaną wartość jako dane nieufne i stosować ochronę odpowiednią dla swojego kontekstu.

Walidacja formularza – praktyczne wskazówki dla użytkownika

Podczas korzystania z formularza warto zwracać uwagę na nietypowe zachowanie strony. Powodem do ostrożności mogą być nagłe przekierowania, pojawianie się obcych komunikatów, zmiana układu po wysłaniu tekstu, automatyczne otwieranie dodatkowych okien, błędy dotyczące kodowania znaków albo wyświetlanie danych należących do innej osoby. Pojedynczy błąd nie przesądza jeszcze o luce, ale powtarzalność objawu, zależność od konkretnego wpisu i występowanie problemu w wielu przeglądarkach uzasadniają dokładniejsze sprawdzenie.

Nie powinno się wprowadzać do formularza danych wrażliwych, jeżeli nie jest jasne, kto jest administratorem systemu, w jakim celu dane są zbierane i czy połączenie jest chronione. Dotyczy to zwłaszcza haseł, kodów dostępu, danych dokumentów oraz informacji finansowych. Przy podejrzanym formularzu można przerwać wysyłanie, zachować opis objawu i zanotować moment jego wystąpienia. Przydatne bywa również zapisanie adresu strony, nazwy pola oraz ogólnego rodzaju wpisu, bez kopiowania poufnej zawartości.

Po stronie osoby odpowiedzialnej za aplikację warto przygotować osobne reguły dla każdego pola. Należy ustalić, które znaki są potrzebne, jaką maksymalną długość ma wartość, czy pole przyjmuje pojedynczy element czy listę, a także w jaki sposób dane będą później używane. Trzeba sprawdzać wartości zarówno przy tworzeniu, jak i przy edycji rekordu. Kontrola powinna obejmować także żądania wysyłane poza standardowym interfejsem, ponieważ samo ukrycie pola albo ograniczenie widoczne w przeglądarce nie jest zabezpieczeniem.

Warto testować formularze z pustymi wartościami, bardzo długimi wpisami, znakami spoza podstawowego alfabetu, znacznikami formatowania, powtarzającymi się separatorami, niepoprawnymi adresami oraz plikami o rozbieżnych nazwach i typach. Testy powinny sprawdzać nie tylko to, czy aplikacja odrzuca błędne dane, lecz także czy komunikat jest bezpieczny, logi nie zapisują nadmiarowych informacji, a odrzucona wartość nie trafia do innego modułu.

Brak filtrowania treści – kiedy zgłosić problem do serwisu

Do serwisu warto zgłosić się wtedy, gdy podejrzane zachowanie formularza występuje na kilku urządzeniach, pojawia się po aktualizacji oprogramowania, utrudnia pracę z panelem administracyjnym albo towarzyszy mu utrata kontroli nad kontem. Szczególnej uwagi wymaga sytuacja, w której po wpisaniu danych zostaje wyświetlona treść innego użytkownika, zmienia się konfiguracja systemu lub pojawiają się nieznane komunikaty. Przed przekazaniem sprzętu dobrze jest opisać kolejność zdarzeń i wskazać, czy problem dotyczy jednego programu, przeglądarki czy całego komputera.

W Warszawskim Pogotowiu Komputerowym 24/7 można skonsultować objawy związane z bezpieczeństwem laptopa, działaniem formularzy oraz podejrzanymi komunikatami. Podczas zgłoszenia przydatne jest przedstawienie zrzutów ekranu bez danych poufnych, informacji o używanym systemie i aplikacji oraz wskazanie, po jakiej czynności pojawiła się nieprawidłowość. Nie należy przekazywać haseł ani kodów uwierzytelniających; jeżeli zachodzi podejrzenie ich ujawnienia, powinny zostać zmienione z bezpiecznego urządzenia.

Ocena problemu powinna obejmować zarówno sam formularz, jak i drogę, którą dane przebywają po wysłaniu. Sprawdzenia wymagają przeglądarka, aplikacja, zapis w bazie, komunikaty, załączniki, konta użytkowników oraz logi zdarzeń. Dopiero takie podejście pozwala ustalić, czy przyczyną jest brak kontroli danych, błąd wyświetlania, uszkodzenie aplikacji, nieprawidłowa konfiguracja czy działanie niepożądanego oprogramowania. Im wcześniej zostanie zabezpieczony dostęp i ograniczone dalsze wysyłanie podejrzanych treści, tym łatwiej zmniejszyć zakres możliwych skutków.