Grupa Unity: walidacja to dla e-sklepu konieczność

Unity

Formularz stanowi podstawowe narzędzie pozwalające na interakcję systemu z klientem. Rejestracja, logowanie lub zmiana hasła to tylko niektóre przykłady jego wykorzystania w sklepie internetowym. Jak zbudować użyteczny formularz, aby klient mógł go poprawnie wypełnić, jednocześnie zapewniając bezpieczeństwo aplikacji? Z pomocą przychodzi walidacja.

Ważnym aspektem rozpatrywanym podczas projektowania formularzy, tuż po decyzji jakie pola powinien on zawierać, jest kwestia zapewnienia klientowi wsparcia w poprawnym wprowadzaniu danych. Numer telefonu komórkowego zawierający znaki nienumeryczne lub sześciocyfrowy kod pocztowy prowadzić będą do błędów aplikacji, a brak filtrowania wprowadzonych danych stanowić może poważną lukę w bezpieczeństwie.

Walidacja – dlaczego to takie ważne?

Przed błędami pomaga chronić walidacja – narzędzie umożliwiające nałożenie na poszczególne pola formularza zbioru pewnych warunków. Warunkiem może być określenie formatu wprowadzanych danych, np. format wspomnianego już kodu pocztowego to XX-XXX, gdzie każdy znak X może być jedynie cyfrą. Innym przykładem warunku jest definicja ilości wprowadzonych znaków numerycznych – np. 9 dla pola numer komórkowy.

Walidacja w kontekście informatycznym oznacza sprawdzenie poprawności oraz zgodności ze zdefiniowanymi regułami. Ma ona dwa podstawowe zadania:

  • pomoc klientowi w poprawnym jego wypełnieniu,
  • zapewnienie bezpieczeństwa aplikacji.

Wykorzystuje się następujące rodzaje walidacji:

  • Frontowa – walidacja danych w przeglądarce, nazywana „walidacją po stronie klienta”. Polega na weryfikacji danych bezpośrednio po, a czasem nawet w trakcie wprowadzania ich w pole formularza. Nie wymaga zatwierdzenia formularza, czy przeładowania strony. Najczęściej walidator uruchamiany jest po przejściu do kolejnego pola formularza lub po kliknięciu w inne miejsce na stronie.
  • Backendowa – walidacja danych w aplikacji, nazywana „walidacją po stronie serwera”. Walidator uruchamiany jest po przesłaniu danych z przeglądarki do aplikacji, ale przed ich dalszą obsługą w systemie. Może on zwrócić do przeglądarki informacje o niepoprawnym uzupełnieniu formularza lub dopuścić do wykonania zaplanowanych operacji na podstawie dostarczonych danych.

Po pierwsze: poprawność

Poprawność danych wprowadzonych przez klienta weryfikować można już na poziomie poszczególnych pól, a nie dopiero po wypełnieniu całego formularza. Pozwala to natychmiast wyświetlić klientowi komunikat i uniknąć konieczności przeładowania strony. Za taką weryfikację odpowiedzialna jest walidacja frontowa. Wykorzystywana jest ona zazwyczaj do weryfikacji poprawności formatu danych – bez logicznej weryfikacji. Nie oznacza to jednak, że logiczna weryfikacja nie jest możliwa.

Walidator porównuje tekst wpisany przez klienta z kryteriami ustalonymi przez projektanta. Oznacza to, że system z góry oczekuje na konkretny typ danych. Dla przykładu prosty walidator pola e-mail oczekuje ciągu znaków oddzielonych od siebie znakiem [email protected] oraz „.”, przy założeniu, że pomiędzy tymi znakami wystąpić powinna określona ilość znaków. Wprowadzenie ciągu niespełniającego powyższy wymóg uniemożliwi przesłanie danych do aplikacji. Kwestię kryteriów jakie narzucane są na pola warto dobrze przemyśleć. Walidator będący dobrą podpowiedzią dla jednych może być nie lada kłopotem dla innych. To samo dotyczy samych pól wykorzystanych w formularzu. Poniżej krótka historia potwierdzająca to zjawisko, opisana z perspektywy klientki sklepu online.

Do niedawna wydawało mi się, że przez ponad 3 lata studiów w internecie kupowałam już wszystko czego potrzebuje w codziennym życiu. Ubrania, kosmetyki, elektronikę, małe AGD, prezenty… a jednak! Czystą przyjemność sprawiają mi zakupy w lokalnym, małym sklepie spożywczym. Choroba zrobiła jednak swoje i zdecydowałam się na zakupy on-line.

Dokonałam rejestracji, wybrałam produkty i… okazało się, że sklep wie jak wygląda moje osiedle, ale nie wie o istnieniu domu o numerze 32E. Fakt, do użytku został dodany niedawno – ale to chyba nie jest znaczące w procesie zamówienia?

Domyślam się, że celem tak skonstruowanego formularza była (aż nadto?) skuteczna eliminacja możliwości realizacji zamówienia złożonego na fałszywy adres. Ale czy ograniczenie użytkowników do określonych adresów jest dobrym rozwiązaniem? W ramach ciekawostki dodam tylko, że w tym samym formularzu przypadkiem udało mi się wprowadzić 4-cyfrowy numer telefonu.

Po drugie: bezpieczeństwo

Klient poprawnie wypełnił formularz i co dalej? Dane trafiają do aplikacji i po raz kolejny powinny być sprawdzone. Walidacja beckendowa dokonuje ponownej weryfikacji typu oraz formatu danych. Dodatkowo pozwala ona na weryfikację pod względem bezpieczeństwa i logiki danego systemu.

Formularz zbudowany bez dogłębnego przemyślenia stanowić może poważną lukę w bezpieczeństwie aplikacji. Dane jakie przychodzą od klientów najczęściej modyfikują bazę danych, której poprawne działanie i spójność kluczowe są dla stabilnego działania systemu. Z tego powodu nie można pominąć również walidacji pod kątem niebezpieczeństwa. SQL Injection, czyli wstrzykiwanie odpowiednio przygotowanych fragmentów zapytań SQL jest jednym z przykładów luk w zabezpieczeniach. Brak walidacji pod tym kątem pozwoli klientowi wykonać niepożądane dla aplikacji zapytania, których konsekwencje zazwyczaj są nieodwracalne.

Należy podkreślić, że dane wprowadzane przez klienta, przed pierwszym ich użyciem koniecznie powinny być zweryfikowane. Pozwoli to odpowiednio wcześnie wykryć i wyeliminować zagrożenie płynące ze strony – świadomego bądź nie – klienta sklepu.

Po trzecie: logika

Dane zostały zwalidowane – mają poprawny typ, format i nie stanowią zagrożenia. To jednak nie koniec. Odpowiednia implementacja pozwoli zweryfikować wprowadzane dane pod kątem logiki danego systemu. Walidacja logiczna polega na sprawdzeniu czy wprowadzone przez klienta dane spełniają określone podczas projektowania aplikacji warunki.

„Podany adres e-mail jest już zarejestrowany. Tutaj możesz skorzystać z opcji przypomnienia hasła” – taka informacja jest przykładem komunikatu wyświetlanego przez walidator zależny od logiki aplikacji. Jeśli loginem klienta jest jego adres e-mail to nie można założyć dwóch kont na ten sam adres e-mail. To przecież jedno z podstawowych założeń systemów, w których login równa się adres e-mail.

Takiego zdarzenia nie możemy wyłapać już na poziomie opisanej wcześniej walidacji frontowej – format e-maila był poprawny. Nie zagraża on również bezpieczeństwu – już kiedyś został przecież wprowadzony. W zgodzie z powyższym założeniem po wprowadzeniu przez klienta danych, weryfikacji frontowej i weryfikacji pod względem bezpieczeństwa przyszedł czas na walidację logiczną – sprawdzenie czy w bazie danych istnieje rekord z wprowadzonym przez klienta adresem e-mail. Jeśli tak – nie można ponownie zarejestrować użytkownika.

Podczas projektowania poszczególnych etapów walidacji formularza bardzo ważne jest aby pamiętać, że:

  • każdy etap walidacji jest niezmiernie ważny i wymaga dokładnego przemyślenia,
  • każdy popełniony błąd stanowić może lukę w bezpieczeństwie aplikacji lub utrudniać wprowadzanie danych,
  • wszystkie etapy powinny być ze sobą spójne.

Autorką artykułu jest Ewelina Wójcik z Grupy Unity. Absolwentka informatyki na Politechnice Krakowskiej. W Grupie Unity pracę rozpoczęła na stanowisku programisty PHP, a obecnie wspiera rozwój platformy Unity Commerce 4.0 jako Analityk Systemowy.

Grupa Unity jest dostawcą rozwiązań IT dla e-biznesu w Polsce. Firma oferuje narzędzia wspierające wielokanałową sprzedaż i dystrybucję, rozwiązania usprawniające procesy w środowisku pracy, a także wdrażanie i integrację dedykowanego oprogramowania.Grupa Unity powstała z połączenia Contium, Internet Designers oraz Empathy-Internet Software House i ma na koncie blisko 50 wdrożeń e-commerce oraz ponad 200 z zakresu e-marketingu i e-biznesu.

Tagi:

Reklama

SCF 2017 Spring