Formularze i walidacja

Formularze to nieodłączny element aplikacji internetowych, dlatego dzisiaj będziemy znęcać się właśnie nad nimi. Jeżeli jako tester poruszasz się w tym kontekście, to z pewnością weryfikujesz w swoich codziennych testach ogromną ilość formularzy korzystając z różnych technik, ale czy sprawdzasz przy okazji bezpieczeństwo? Wbrew pozorom podstawowa weryfikacja nie jest wcale taka trudna – podpowiem ci dzisiaj kilka sztuczek, dzięki którym twoje testy staną się jeszcze lepsze, a walidacja nie będzie mieć przed tobą tajemnic.

Natywna walidacja w HTML5

Na wstępie wspomnę, że nie każda przeglądarka wspiera walidację HTML5 – do poniższych przykładów rekomenduję używać przeglądarki Chrome lub Firefox w najnowszej wersji.

Testując formularze – oprócz weryfikacji pozytywnych ścieżek, potwierdzających prawidłowe działanie systemu – prawdopodobnie testujesz też przypadki negatywne. Zakładam, że w tym celu wpisujesz różne wartości, które mogą zostać nieprawidłowo obsłużone przez aplikację zwracając niespodziewane rezultaty. Podczas przeprowadzania testów bezpieczeństwa również stosuję podobną technikę, mającą na celu wywołanie jak największej ilości błędów w aplikacji – fuzzing. Pomocne w tym procesie jest narzędzie Burp Suite (lub OWASP ZAP), które trochę dokładniej opisałem w tym artykule (jeżeli chcielibyście dowiedzieć się więcej o tym, jak przeprowadzać fuzz testy przy użycia Burp’a, to dajcie znać w komentarzach).

Przed wprowadzaniem niepoprawnych lub potencjalnie groźnych danych, chroni nas walidacja. W zasadzie możemy podzielić ją na dwa typy – walidację po stronie klienta i po stronie serwera. Ta pierwsza jest prosta w implementacji – zwłaszcza, jeżeli skorzystamy z dobrodziejstw HTML5. Przykładowo, jeżeli chcesz żeby pole tekstowe w twoim formularzu było sprawdzane pod kątem poprawności adresu e-mail, wystarczy że jako jego typ podasz wartość „email”:

Formularze, które znajdziesz poniżej nie robią nic specjalnego – możesz użyć ich śmiało jako poligon treningowy.

<input type="email" name="user_mail" />

Wprowadź adres e-mail:

 

Możesz spróbować wpisywać wartości, które nie powinny zostać zaakceptowane jako adres email (bez większego problemu powinno ci się udać znaleźć także takie, które walidacja przepuści pomimo, że nie powinna). Jest też prostsza opcja – kliknij prawym przyciskiem myszki na polu do wprowadzania adresu email i wybierz opcję „Zbadaj element”. Następnie, korzystając z DOM Explorer’a i mając zaznaczony wybrany obiekt (tag input, o nazwie user_mail), kliknij dwa razy na wartość atrybutu „type” i zmień ją z „email” na „textbox”, a następnie zatwierdź całość klikając enter.

Dom Explorer - Walidacja

Gratulacje, właśnie udało ci się obejść zabezpieczenie w postaci walidacji po stronie klienta i możesz wprowadzić dowolną treść w pole e-mail. Chcesz poćwiczyć na innych przykładach? Poniżej wrzucam ci kilka formularzy (to samo możesz zrobić z polami typu disabled, czy required – po prostu je usuń) – have fun!

 


Wprowadź liczbę całkowitą


Wprowadź adres url


Wprowadź datę


Wprowadź liczbę całkowitą większą niż 10


Wprowadź liczbę całkowitą (pole nie może być puste)


To pole jest nieaktywne


 

Czy to oznacza, że walidacja po stronie klienta nie ma sensu, skoro tak naprawdę przed niczym nie chroni? Przede wszystkim, jej założeniem nie jest ochrona przed atakami. Celem walidacji po stronie klienta jest poprawienie user experience. Dzięki zastosowaniu tego rozwiązania klient otrzymuje informację zwrotną bardzo szybko, bez niepotrzebnego kontaktu z serwerem. Prawdopodobnie domyślasz się już, że prawidłowym rozwiązaniem w tym wypadku jest zastosowanie walidacji także po stronie serwera, której zadaniem będzie powstrzymywanie bardziej ciekawskich użytkowników 🙂

Ukryte pola formularza

W ukrytych polach formularza, przetrzymywane są dane które mają zostać wysłane do serwera razem z formularzem, natomiast nie muszą być wyświetlane użytkownikowi. Jest to po raz kolejny rozwiązanie podnoszące user experience – użytkownik widzi tylko te dane, które są mu niezbędne do przeprowadzenia operacji. Należy jednak stosować to rozwiązanie z rozsądkiem i pamiętać jakie konsekwencje mogą się z nim wiązać. Szczególnie groźnym przypadkiem może być przechowywanie wrażliwych informacji w tzw. hidden field’ach. Należy pamiętać, że takie dane przetrzymywane są po stronie klienta i to on kontroluje wartości które zostały tam wprowadzone. Przykładowe ukryte pole możecie znaleźć w formularzu poniżej – aby je wyświetlić lub edytować wartość ponownie skorzystaj z DOM explorer’a – zmień typ pola o nazwie „ukryte_pole” z hidden na textbox:

<input type="hidden" name="ukryte_pole" value="ustalona wartość" />

 


Udało ci się zamienić ukryte pole na textbox? Wystarczyło edytować jego typ – to samo możesz zrobić z jego wartością. Przy kolejnych testach funkcjonalnych pamiętaj również o tym, żeby przetestować ukryte pola – one także są przetwarzane przez aplikację. Polecam wtyczkę do Firefoxa o nazwie Web Developer – dzięki niej wchodząc na stronę możecie użyć opcji „Różne” -> „Wyświetl ukryte elementy” co – jak się pewnie domyślasz – spowoduje wyświetlenie wszystkich ukrytych elementów na stronie, w tym hidden field’ów (czy też elementów strony, które ktoś ukrył dodając atrybut display: none;).

Walidacja Web developer - plugin

Bonus

Masz w swojej aplikacji możliwość wgrania pliku na serwer? Na przykład strona profilu użytkownika, który może wgrać swoje zdjęcie profilowe? Oczywiście (w zależności od tego czy programista użył podejścia białej, czy czarnej listy) użytkownik nie może wrzucić dowolnego rozszerzenia pliku a jedynie taki, który nie jest potencjalnie groźny. Sprawdź, czy uda Ci się wgrać plik z innym rozszerzeniem niż dopuszczalne – będziesz do tego celu potrzebować Burp’a. Mając formularz z dostępnym uploadem plików załaduj taki (ale jeszcze nie klikaj wysłania pliku do serwera!), który powinien przejść walidację – w moim przypadku będzie to jpg.

Następnie włącz opcję Intercept na Burpie i wyślij formularz.

Mając „złapany” request zmień jego zawartość z wgrywanego .jpg na .php (musisz podglądnąć w innym miejscu, jak powinien wyglądać request odpowiedzialny za wysłanie pliku .php, „łapiąc” go w ten sam sposób za pomocą Burp’a).

Sprawdź, czy plik znalazł się na serwerze?

Jeżeli odpowiedź na ostatnie pytanie jest pozytywna to gratuluję – zaraportuj błąd związany z bezpieczeństwem 🙂