Na co narażone są formularze logowania?
- Poniżej opisałem najpopularniejsza ataki i problemy, jakie napotkałem podczas pracy z różnymi serwisami internetowymi oraz ich autorami.
- Poniższa lista nie jest kompletna, a tysiące ludzi na całym świecie codziennie pracuje nad coraz to bardziej wyszukanymi metodami ataku i pozyskania danych z formularzy do logowania.
- Umieszczone w artykule zagadnienia opisane są w kontekście formularza do logowania, jednakże ich problematyka ma dużo szersze znaczenie.
Odczyt niezaszyfrowanych danych
Zgodnie z podstawowymi zasadami działania Internetu, zanim dane wysłane z komputera użytkownika logującego się do systemu trafią do serwera docelowego, to przechodzą przez dziesiątki innych komputerów, gdzie są odczytywane i przekazywane dalej, aż dotrą do miejsca docelowego. Oznacza to, że każdy z komputerów, który „przekazał dalej” dane niezbędne do zalogowania mógł je odczytać i poznać ich treść. Większość osób uważa, że to bardzo trudne, ale to nic bardziej mylnego. Gotowe, darmowe programy dostępne w sieci bez problemu radzą sobie z odczytaniem tych informacji i nie wymagają od użytkownika zaawansowanej wiedzy.
Blokada konta użytkownika
W wielu serwisach można spotkać się z różnego rodzaju zabezpieczeniami, które blokują konto użytkownika po określonej liczbie nieudanych logowań. Zablokowane konto nie jest dostępne przez określony czas lub blokada wymaga kontaktu z administratorem serwisu. Wystarczy więc celowo kilkukrotnie błędnie wpisać hasło użytkownika, aby doprowadzić do blokady konta. Problem nabiera szczególnego znaczenia, gdy mamy do czynienia na przykład z systemem aukcyjnym. Widząc osoby, które licytują dany przedmiot, atakujący może tuż przed końcem aukcji dokonać blokady ich konta i uniemożliwić zakup produktu. Eliminacja konkurencji to najlepszy sposób na rozwiązanie problemu.
Odczyt danych metodą ataku słownikowego (ang. brute force)
Aktualna moc obliczeniowa przeciętego komputera stacjonarnego jest wystarczająca, aby w relatywnie krótkim czasie złamać nieskomplikowane hasło użytkownika lub przy większej cierpliwości nawet to bardziej złożone. W sieci istnieje bardzo wiele gotowych programów, które odpowiednio skonfigurowane przeprowadzą automatyczny atak. Może nie jest to najbardziej wydajna i wyrafinowana metoda, ale efekt końcowy jest taki sam: atakujący uzyskuje dostęp do konta użytkownika.
SQL injection
Zdecydowana większość serwisów internetowych przechowuje informacje w bazach danych, w których komunikacja odbywa się za pomocą języka zapytań SQL (lub mu podobnych). SQL injection to forma ataku polegająca na wstrzyknięciu określonej sekwencji znaków do strony internetowej w celu wyświetlenia lub modyfikacji informacji zawartych w bazie danych bądź spowolnienia, uszkodzenia lub całkowitego wyłączenia systemu bazodanowego.
Cross-site scripting
Atak cross-site scripting (XSS) polega na nieświadomym wykonaniu zewnętrznego kodu programistycznego przez użytkownika logującego się do systemu. Atakujący odpowiednio wcześniej wstrzykuje do strony kod programistyczny, który modyfikuje działanie strony. Wstrzyknięty kod może na przykład wysyłać wprowadzone dane do logowania na zewnętrzne serwery lub automatycznie je publikować na odpowiednio przygotowanych do tego celu stronach internetowych.
Najczęstsze błędy popełniane podczas tworzenia formularzy logowania
Hasło przechowywane w postaci jawnej
Włamania, wycieki danych, brak odpowiedniej hermetyzacji to codzienność naszego świata. Możemy się przed nimi zabezpieczać, ale zawsze prędzej czy później znajdziemy się w sytuacji, że dane użytkowników strony lub sklepu internetowego zostaną udostępnione w sieci. Może to być na przykład błąd pracownika firmy lub jego celowe działanie, błąd serwera, na który nie mamy wpływu lub nawet języka programowania. Nie zawsze wiąże się to z włamaniem na stronę. Ważne jest jednak to, w jaki sposób zabezpieczyliśmy nasze dane przed tego rodzaju awarią. Nawet największe firmy takie, jak Apple, Microsoft, czy Google kilka razy miały do czynienia z nieautoryzowanym udostępnieniem prywatnych danych swoich użytkowników (o czym możecie przeczytać w sieci).
Sam wyciek danych jest niebezpieczny, ale nie oznacza końca świata. Jeśli dane użytkowników (np. hasło), były przechowywane w bazie danych w postaci jawnej, niezaszyfrowanej to atakujący uzyskał pełen dostęp od ich informacji. Jest to bardzo niebezpieczne. Jeśli jednak dane były odpowiednio zabezpieczone, to nawet po ich otrzymaniu atakujący ma duże problemy z ich wykorzystaniem.
Hasło przechowywane w postaci zaszyfrowanej
Wiele osób uważa, że przechowywanie hasła w postaci zaszyfrowanej rozwiązuje ich problemy, ale to nic najbardziej mylnego. Każdy szyfr można odczytać, a algorytm jego odczytania najczęściej znajduje się na serwerze, do którego właśnie się włamaliśmy. Tym samym odczyt danych wcale nie jest taki trudny, jak nam się wydaje. Dodatkowo do szyfrowania najczęściej używane są proste algorytmy, aby dostęp do danych był szybki i nie wymagał dużej mocy obliczeniowej, a to powoduje, że nawet bez algorytmu deszyfrującego zdolny kryptograf jest w stanie złamać użyty algorytm i udostępnić dane użytkowników w Internecie.
Hasło przechowywane w postaci hashu
Hash hasła, zwany również funkcją skrótu, to w dużym uproszczeniu rodzaj algorytmu jednostronnie szyfrującego ciąg znaków. Oznacza to, że raz zahashowane hasło nie da się już ponownie odszyfrować, ale da się porównać. Właściwość ta świetnie się nadaje, aby zapisać hasło w bazie danych i uniemożliwić jego odczytanie. Nawet jeśli mamy dostęp do bazy danych, to nie widzimy rzeczywistego hasła, tylko jest zahashowany odpowiednik, który nic nie znaczy. Wg większości programistów to najlepsza metoda zapisywania haseł w bazie danych i oczywiście ich największy błąd. Skoro mogę hash hasła porównać, to mogę napisać algorytm, który metodą słownikową porówna hash losowego hasła z tym, co jest bazie danych i znajdzie ich odpowiednik. Tym samym powstały już gigantyczne bazy danych z gotowymi rozwiązaniami, które radzą sobie z odczytaniem większości używanych przez użytkowników haseł. Dodatkowo bardziej zaawansowani programiści przy wykorzystaniu specjalnych tablic tęczowych potrafią złamać każde hasło.
Ten błąd spotykałem w ponad 90% obsługiwanych przeze mnie stron internetowych. Jest naprawdę bardzo powszechny.
Jawne hasło wysyłane za pomocą metody GET
Formularze logowania wysyłane za pomocą metody GET, czyli w adresie url strony internetowej są tylko pozornie bezpieczne. Mają dwie największe wady:
- Przeglądarka zapamiętuje wpisywane adresy url, a tym samym w jej historii lub automatycznych podpowiedziach może znaleźć się również hasło użytkownika.
- Algorytmy do badania ruchu na stronie i pozycjonowania takie, jak Google Tag Manager lub Google Analytics zapisują adresy url, a tym samym również hasła, które w nich się znajdują. Być może mamy zaufanie do agencji SEO, która prowadzi naszą stronę internetową, ale i tak nie powinni oni mieć dostępu do jawnych haseł użytkowników firmy.
Blokada dostępu do konta po kilku nieudanych próbach zalogowania
Blokadę logowania wykorzystują najczęściej serwisy, które mają problemy z atakami słownikowymi (ang. brute force). Ataki tego rodzaju są dużym obciążeniem dla serwera oraz wielkim niebezpieczeństwem dla ochrony prywatności jego użytkowników. Każde hasło można prędzej czy później złamać, wystarczy tylko odpowiednio długo poczekać. Wg uśrednionych statystyk tylko 10% wszystkich haseł jest dłuższa niż 12 znaków. To bardzo niepokojące statystyki. W prawidłowej konfiguracji serwera podczas ataku metodą słownikową system powinien zablokować zapytania atakującego, nie blokując przy tym żadnego konta użytkownika. Niestety, firmy świadczące usługi serwerowe bez kontaktu z właścicielem serwisu nie zawsze są w stanie prawidłowo rozpoznać ataku brute force, a tym samym odpowiednio wcześnie go zablokować. Dobrze przygotowany atakujący zna protokoły bezpieczeństwa serwerowni i wie, jak bardzo może sobie pozwolić, aby jego atak nie został zablokowany. To powoduje, że programiści często sami tworzą zabezpieczenia w serwisach internetowych, które mają za zadanie chronić prywatność ich danych. Niestety, nie są doskonałe. Tak, jak opisałem kilka akapitów wyżej, najczęściej wiążą się one z zablokowaniem możliwości logowania na dane konto, aby uniemożliwić dostęp do jego prywatnych danych. Z prawnego punktu widzenia bezpieczniej jest zablokować dostęp niż udostępnić wrażliwe dane osobowe. Blokada konta wymaga kontaktu z administratorem i długiego czasu oczekiwania. Jest kosztowna dla firmy, ponieważ wymaga zatrudnienia administratora, który będzie tego rodzaju zgłoszenia weryfikował oraz problematyczna dla użytkowników, gdyż ich konto zostało zablokowane.
Opóźnienie następnej próby zalogowania po nieudanym logowaniu
Metoda opóźnienia kolejnej próby zalogowania jest teoretycznie lepszym rozwiązaniem, niż kompleta blokady konta (czytaj akapit wyżej). Nie wymaga ona kontaktu z administratorem serwisu, a tym samym firma nie musi zatrudniać specjalisty, co obniża jej koszty utrzymania. Niestety, ta metoda nie rozwiązuje problemu:
- Czasowa blokada konta nie daje żadnej gwarancji, że po upływie czasu blokady atak się nie powtórzy. Jeśli atakujący zdaje sobie sprawę z istnienia blokady, to odpowiednio przygotuje sekwencyjny algorytm ataku.
- Skoro żaden specjalista, nie weryfikuje tego rodzaju zapytań, to nie mamy żadnej kontroli nad tym, co dzieje się w serwisie. Podczas ataków wydajność serwera znacząco spada, a my nie wiemy, kiedy i które zabezpieczenia zostały złamane. Strona internetowa działa wolniej, a cierpią na tym wszyscy jej użytkownicy.
- Opóźnienie kolejnej próby logowania wciąż blokuje dostęp do konta, a to oznacza, że osoba, która ma uprawnienia do konta, wciąż nie może z niego skorzystać.
- Po zablokowaniu jednego konta atakujący wciąż może atakować kolejne. Jeśli atak nie jest ukierunkowany na konkretne konto, to blokada czasowa niczego nie zmienia.
Publiczny identyfikator (login) konta
To wg mnie najbardziej niedoceniany problem z zakresu bezpieczeństwa, który występuje w większości stron internetowych, nawet w tych największych (np. Google, Apple, Microsoft). Istnieje również w każdej stronie opartej na systemie CMS WordPress.
Jeśli do logowania używamy adresu e-mail lub loginu, który jest publiczny, powszechnie znany (np. nazwa autora lub jego slug w adresie url) to atakującemu już na starcie udostępniamy 50% informacji, jakie potrzebuje do udanego ataku na dane konto. To jakbyśmy podali mu połowę naszego hasła. Atakujący, który zna nasz login, może dokonać kierowanego ataku na konkretne konto.
Wyobraźmy sobie klasyczny sklep internetowy. W takim sklepie mamy tysiące kont użytkowników, które nie mają żadnych uprawnień, poza możliwością zakupu produktów w sklepie. Z tysiąca kont, istnieje tylko i wyłącznie kilka, które mają uprawnienia administratora. W przypadku ataku na stronę, gdzie identyfikatory kont użytkowników są publiczne, atakujący może wybrać konto z najwyższymi uprawnieniami i za jednym zamachem uzyskać dostęp do wszystkich. W przypadku gdy loginy do konta nie są publiczne, to atakujący ma utrudnienie, bo nie wie, na które konto obecnie się włamuje i jakie ma ono uprawnienia.
Logowanie przy użyciu mechanizmów CAPTCHA
Mechanizmy CAPTCHA (ang. Completely Automated Public Turing test to tell Computers and Humans Apart) są to algorytmy, które mają za zadanie w sposób automatyczny odróżnić człowieka od robota internetowego. Najczęściej są to obrazki, na których napisany jest niewyraźny tekst do przepisania lub proste działanie matematyczne do wykonania. Obrazkowe zadanie dla robota internetowego jest trudne w zrozumieniu, ale dla człowieka w miarę intuicyjne. Niestety wraz z rozwojem sztucznej inteligencji i pojawieniem się zaawansowanych algorytmów takich, jak Google Bard czy ChatGPT okazuje się, że obecnie dostępne na rynku mechanizmy CAPTCHA są niewystarczające. Znacząco zwiększają ilość zablokowanych zapytań, ale nie dają stuprocentowej gwarancji bezpieczeństwa. W sieci co jakiś czas pojawiają się nowe informacje, w których autorzy opisują, w jaki sposób można złamać popularne zabezpieczenia przeciwko robotom internetowym. Im większa popularność danego zabezpieczenia, tym więcej osób stara się je złamać, a tym samym powstaje więcej gotowych rozwiązań o różnym stopniu skuteczności.
Biała lista
Białą listą nazywamy grupę identyfikatorów użytkowników (najczęściej adresów IP), którzy mają uprawnienia do zalogowania się do systemu. Jeśli ktoś nie znajduje się na liście, to nie może się zalogować. Teoretycznie jest to dobre zabezpieczenie, kiedy dostęp do strony ma posiadać tylko stała, nieliczna grupa osób, która loguje się do serwisu, tylko w określonych lokalizacjach (posiada stały adres IP). W praktyce atakujący wykorzystuje technikę zwaną IP spoofing, czyli podszywania się pod inny adres IP, który znajduje się na białej liście. Algorytm białej listy nie jest w stanie rozpoznać atakującego od rzeczywiście uprawnionego użytkownika, a więc atakujący zyskuje dostęp do serwisu.
Rozwiązanie również kompletnie nie sprawdza się, kiedy do serwisu może zarejestrować i zalogować się dowolna osoba lub kiedy adresy IP użytkowników nie są stałe. W takich przypadkach administrator nie może ustalić stałej listy adresów i ograniczyć dostępu.
Czarna lista
Czarną listą nazywamy grupę identyfikatorów użytkowników (najczęściej adresów IP), którzy mają zablokowany dostęp do serwisu. Jeśli ktoś znajduje się na czarnej liście i wprowadzi prawidłowe dane dostępowe (login i hasło), to algorytm czarnej listy wciąż będzie traktować go, jako osobę niezalogowaną. Podobnie, jak w przypadku białej listy jest to rozwiązanie, które nie zapewnia bezpieczeństwa, ponieważ atakujący w bardzo prosty sposób może zmienić swój adres IP i korzystać z identyfikatora, który na czarnej liście się nie znajduje.
Historia logowania i ostatnich aktywności
Na wielu stronach, po autoryzacji można znaleźć historię logowań lub ostatnich aktywności na koncie. Taka lista niestanowi bezpośredniego zabezpieczenia przed włamaniem, ale pozwala właścicielowi konta zidentyfikować problem i zgłosić go do administratora serwisu. Jest też świetnym narzędziem dla programisty, które pozwala przejrzeć historię zmian na koncie i zweryfikować potencjalne błędy na stronie www. To rozwiązanie ma niestety wady:
- Wg badań zdecydowana większość użytkowników nie sprawdza systematycznie historii logowania i historii ostatnich aktywności. Tym samym nie weryfikuje jej, do czasu aż zauważy jakiś problem na koncie, a wtedy najczęściej jest już za późno.
- Historia jest świetnym narzędziem dla programisty, jak i dla atakującego. Atakujący, który dostanie się na konto, widzi pełną aktywność konta i może ją wykorzystać do własnych celów (np. phishing) .
Dostęp do bazy danych z poziomu wielu różnych aplikacji
Duże firmy wykorzystują różne kanały do pozyskiwania klientów i zarabiania pieniędzy. W tym celu budują różne aplikacje, serwisy internetowe, programy CRM, CMS, CMMS, ERP, WMS itd, które najczęściej bazują na jednej bazie danych klientów. Każda z tych aplikacji tworzona jest przez inny zespół programistyczny, o różnej wiedzy, umiejętnościach i kompetencjach dotyczących bezpieczeństwa. Wystarczy więc, że jedna z nich popełni błąd (np. jeden z opisanych w tym artykule), a atakujący uzyskuje dostęp do wszystkich powiązanych aplikacji. Bardzo ciężko jest utrzymać ten sam poziom bezpieczeństwa w różnych aplikacjach, które tworzone są przez różne zespoły programistyczne.
Wtyczki, rozszerzenia i kody zewnętrznych firm
Gotowe rozwiązania takie, jak wtyczki, dodatki i rozszerzenia są bardzo tanim i szybkim sposobem na uzyskanie pożądanej funkcjonalności na stronie www. W takich przypadkach najczęściej to nie my musimy martwić się o bezpieczeństwo, bo robią to za nas twórcy wtyczki. Jest to największy błąd, jaki popełniamy. Kody źródłowe wszystkich rozszerzeń są ogólnodostępne. To znaczy, że każdy programista może je przeczytać, znaleźć ich błędy i wykorzystać do własnych celów. Tylko najpopularniejsze dodatki, które mają wysokie dochody, mogą posiadać odpowiednie zasoby, aby odpowiednio się zabezpieczyć i przeprowadzać odpowiednie, cykliczne testy bezpieczeństwa. W większości przypadków twórcy wtyczek reagują na podatności tylko i wyłącznie wtedy, gdy ktoś im to zgłosi (i z doświadczenia powiem, że nie zawsze). Czyli to klient ponosi koszty włamania, strat i weryfikacji problemu, a twórca dodatku dostaje gotową informację, co ma poprawić. Przy wysokobudżetowych serwisach www, należy zastanowić się, co tak naprawdę jest bardziej opłacalne.
Drugim aspektem jest przetwarzanie danych osobowych. Wtyczki przetwarzają dane osobowe. Przed ich instalacją należy upewnić się, jakie dane są przetwarzane i czy jest to zgodne z naszą polityką prywatności.
Ostatnim problemem, z którym często mamy do czynienia jest spustoszenie wtyczki, które robi w bazie danych po jej dezinstalacji. Po usunięciu rozszerzenia w zdecydowanej większości przypadków baza danych nie ulega oczyszczeniu i pozostają w niej informacje, które wtyczka wykorzystywała lub modyfikowała. Jeśli były to dane dotyczące logowania, to warto upewnić się, czy po wyłączeniu wtyczki te dane nie zostały w jakiś sposób upublicznione. Działająca wtyczka często blokowała dostęp do tych danych, ale po jej wyłączeniu dane często pozostają podatne na atak cyberprzestępcy.
Rozwiązanie wszystkich problemów bezpieczeństwa
Jedyną znaną i rekomendowaną przeze mnie metodą na zabezpieczenie swojego formularza do logowania jest skorzystanie z usług doświadczonego specjalisty, który jest świadomy opisanych powyżej problemów, potrafi je rozwiązać i wykorzystać swoją wiedzę do odpowiedniego zabezpieczenia formularza logowania i przechowywania wrażliwych danych. To właśnie nieświadomość oddziela firmy programistyczne od siebie. Gdyby programista wiedział, że robi źle, to od razu starałby się poprawić. Niestety dowiaduje się tego, dopiero gdy dochodzi do nieszczęścia. Żadne gotowe rozwiązania nie zabezpieczą strony internetowej w sposób wystarczający. Tylko wiedza to potęgi klucz.
