Niebezpiecznik

Czy wiesz, jak niebezpieczna potrafi być funkcja przypominania hasła? Co prawda pozwala ona użytkownikom na dostanie się do serwisu w sytuacji, w której zapomnieli swoich danych dostępowych, ale jest też bardzo pomocna dla wszelkiej maści włamywaczy no i oczywiście testerów bezpieczeństwa aplikacji webowych. Zwłaszcza, jeśli zostanie zaimplementowana w nieodpowiedni sposób. W tym artykule przyjrzymy się najczęstszym wpadkom popełnianym przez programistów właśnie podczas implementacji mechanizmu przypominania hasła.

Zapraszamy do lektury kolejnego artykułu z serii “Poradnik Hackowania Webaplikacji“.

Aby nie przegapić kolejnych artykułów z tej serii, poświęconych błędom w serwisach internetowych i technikom testowania webaplikacji, zapisz się do naszego tematycznego newslettera — poza powiadomieniami o kolejnych artykułach otrzymasz od nas także dodatkowe przydatne materiały (linki, narzędzia i infografiki), które wysyłać będziemy tylko subskrybentom tego newslettera e-mailem (nie zostaną opublikowane na Niebezpieczniku).

Wpisz adres e-mail:

Rozwiąż Captcha:

HP

Bez obaw, podanych e-maili nikomu nie przekazujemy i wykorzystamy je wyłącznie do przekazywania Ci treści związanych z cyberbezpieczeństwem. Jeśli lubisz czytać o RODO, kliknij tutaj.

Aby rozpocząć analizę tego, co może pójść źle, zacznijmy od rozpisania procesu przypominania hasła na etapy. Zazwyczaj wygląda on następująco:

1. Aplikacja pyta użytkownika o maila
2. Aplikacja wyświetla komunikat o wysłaniu maila
3. Aplikacja wysyła maila z linkiem do zmiany hasła
4. Użytkownik klika linka
5. Użytkownik podaje dwukrotnie nowe hasło
6. Aplikacja aktualizuje hasło użytkownika w bazie
7. Użytkownik loguje się nowym hasłem do systemu

Każdy z tych etapów może posiadać błędy, które okażą się tragicznymi. Zacznijmy od bardzo częstego problemu:

Możliwość enumeracji kont użytkowników

Przy pomocy formularza “przypominania/resetowania” hasła spróbować sprawdzić, czy wybrany użytkownik posiada konto w danym serwisie. Nie postrzegasz tego jako zagrożenia? Nie jest niczym strasznym, że dowiesz się, o tym, że Twój sąsiad ma konto w popularnym sklepie? Wszystko zależy od kontekstu….

Być może informacja o posiadaniu konta na portalu w którym ma go miliony Polaków nie jest szczególnie wrażliwą informacją, ale jeśli uda nam się udowodnić, że wspomniany sąsiad posiada konto w jakimś mniej znanym i bardzo specyficznym serwisie, to może to być traktowane jako naruszenie prywatności. Wyobraźmy sobie, że mamy klinikę medyczną o nazwie “Radosny Medyk”, która specjalizuje się w leczeniu jednej, konkretnej dolegliwości, która do tego jest bardzo wstydliwa. Jeśli uda nam się potwierdzić, że nasz sąsiad posiada w tej klinice konto pacjenta, to w zasadzie dowiedzieliśmy się czegoś o jego problemach zdrowotnych a może nawet hulaszczym trybie życia.

Dlatego lepiej zabezpieczyć swój kod w taki sposób, aby przeprowadzenie wspomnianego ataku nie było możliwe. A żeby tzw. “enumeracja użytkowników” nie była możliwa, musimy zadbać o poprawne komunikaty z błędami przy resetowaniu hasła. Niedopuszczalne są komunikaty, które zdradzają istnienie lub brak istnienia konta w systemie, np.: “nie ma takiego konta”, “konto zablokowane”, “to konto nie zostało jeszcze aktywowane”. Komunikat zwracany przez funkcję przypominania hasła powinien być zawsze taki sam, niezależnie od tego, jaki status ma wybrane konto w systemie. Przykładowo, możemy poinformować użytkownika:

“Jeśli podany adres jest w naszej bazie, to otrzymasz od nas maila z linkiem do zmiany hasła”

Komunikat ten wyświetlamy dla kont zarówno istniejących, jak i nieistniejących.

Wariant z atakiem czasowym

Ale sama treść komunikatu, to nie wszystko. Może się zdarzyć, że atakujący wpisując istniejący adres mailowy widzi, że otrzymuje odpowiedź od backendu raz w 600ms, a raz szybciej, np. w 250ms. Wtedy mamy do czynienia z atakiem czasowym, który wynika z tego, że nasz algorytm może podążyć dwoma ścieżkami. Jedna droga to “jeśli użytkownik istnieje, wyślij maila i wyświetl komunikat”, a druga to “jeśli użytkownik nie istnieje, wyświetl komunikat”. Pierwsza z nich trwa dłużej, bo obejmuje zadanie wysyłki maila realizowane w tym samym wątku.

Aby pozbyć się tej podatności, najprościej będzie zaimplementować akcje asynchronicznie. W praktyce wygląda to tak, że adres mailowy podany przez użytkownika trafia (bez sprawdzania, czy istnieje, czy nie) na kolejkę adresów do przypomnienia, a zewnętrzny system (co pewien czas) sprawdza maile z kolejki i jeśli znajdzie tam adres istniejący w bazie użytkowników, to wysyła im linka do resetu hasła. Komunikat zaś pojawia się na front-endzie od razu.

Atak masowy

Może się zdarzyć, że atakujący oskryptuje nasz formularz przypominania hasła i przeprowadzi atak enumeracji kont na masową skalę, np. sprawdzając dziesiątki tysięcy adresów e-maili, niepotrzebnie obciążając nasze systemy i generując niepokój wśród użytkowników, którzy nagle otrzymają e-maile dotyczące resetu hasła, których się nie spodziewali. Ale i przed tym możemy się zabezpieczyć. Oto dwie metody, które powinny być zaimplementowane równocześnie.

Metoda pierwsza:

Zapisuj w bazie, kiedy (timestamp) wysłany był ostatni mail resetujący hasło dla danego konta oraz ile tych wiadomości wysłano. Jeśli atakujący użyje opcji przypominania hasła, prawdopodobnie zobaczy także linka w stylu “nie dostałeś maila? kliknij tutaj, aby wysłać go ponownie”. Link ten może być wywołany setki, czy nawet tysiące razy, powodując zaspamowanie ofiary wiadomościami z naszej aplikacji.

Trzymanie w bazie ostatniego znacznika czasowego kiedy wysłano maila pozwoli nam na implementację komunikatu mówiącego, że powtórne wysłanie wiadomości możliwe jest dopiero po np. 2 minutach od poprzedniej wiadomości. Ograniczy to problem spamowania, ale ktoś zdeterminowany wciąż może wysłać dziennie 1440 wiadomości (liczba minut w dobie) do nie jednego, użytkownika, a w najgorszym scenariuszu każdego z użytkowników!

Aby to ograniczyć, możemy dodać licznik wysyłanych wiadomości. Jego wartość powinna być zwiększana o 1 przy każdym wysłanym mailu do danego użytkownika (i resetowana po prawidłowej zmianie hasła). Jeśli licznik osiągnie wartość np. 5-10 (wybieramy w zależności od uznania), to na stronie możemy wyświetlić użytkownikowi komunikat:

“Liczba prób odzyskania hasła dla tego adresu została wyczerpana. Jeśli nie otrzymałeś żadnego z wiadomości, prosimy o kontakt mailowy lub telefoniczny z pomocą techniczną”

Ochronę pojedynczego konta przed spamem mamy załatwioną, ale co jeśli ktoś zacznie po kolei dla setek kont wykonywać funkcję, nawet z 2 minutowym opóźnieniem między “strzałami”? Tu z pomocą przyjdzie

Metoda druga:

Możemy zapisywać w bazie adres IP wraz z adresami mailowymi, dla których dany adres IP próbował zresetować dostęp. Jeśli zauważymy, że jeden adres IP odzyskuje hasła dla dziesiątek różnych kont, to nie jest to coś, co powinniśmy tolerować. Warto jednak pamietać, że za jednym IP może ukrywać się niekoniecznie jeden człowiek, a np. spora firma czy akademik. Blokada adresu może być więc kiepskim pomysłem. Lepiej narzucić limit (jak w metodzie pierwszej) dla konkretnego adresu IP, czyli sprawić, aby możliwe było np. uruchomienie procedury resetu hasła dla np. maksymalnie 2 kont w okresie 3 minut. To poważnie spowolni poczynania agresora, nie odcinając naszych użytkowników od funkcji resetu hasła.

Błedy w linku do resetu hasła

Czas na wysyłkę e-maila do użytkownika. Wewnątrz takiej wiadomości najczęściej znajduje się link z hashem do resetu hasła. Aby ten link był “bezpieczny”, musimy zadbać o kilka rzeczy.

• Link powinien być losowy, co oznacza, że za każdym razem będzie inny (posolony hash z loginu, to naprawdę nie jest dobry pomysł)
• Hash powinien mieć swoją datę ważności (np. 1 godzina) i być jednorazowy, aby po wycieku e-maili, np. miesiąc później, ktoś inny nie mógł wykorzystać tego linka do ponownej zmiany hasła

Kolejna warstwa ochrony?

Na dalszym etapie, użytkownik klika linka z wiadomości, ustawia nowe hasło i gotowe. Tylko skąd wiadomo, że osoba klikająca, to prawowity właściciel konta? Istnieje szansa, że agresor czyta pocztę ofiary lub wyłudził od niej linka do zmiany hasła np. w trakcie ataku phishingowego. Jak zweryfikować tożsamość klikającego? Możemy zrobić to na dwa sposoby.

A. Pytanie o login

Jeśli do Twojej aplikacji użytkownik loguje się czymś innym niż mailem, czyli np. ma nadany losowy i niepowtarzalny identyfikator użytkownika, to możesz o niego zapytać podczas zmiany hasła. Zadajesz więc użytkownikowi pytanie: “Dla jakiego loginu chcesz przeprowadzić zmianę hasła?”. Atakujący może tam wpisać co zechce, ale mechanizm po stronie serwisu WWW powinien zareagować jedynie, gdy wpisany ID użytkownika będzie poprawny. Musimy tutaj oczywiście limitować liczbę nieudanych prób i np. po trzech niepoprawnych identyfikacjach unieważnić linka.

B. Pytania bezpieczeństwa

Jeśli podczas zakładania konta prosiłeś użytkownika o wybranie lub ustalenie pytań pomocniczych (nazwisko panieńskie matki, nazwisko przyjaciela z podstawówki, itp.) to teraz masz szansę o to zapytać. Podobnie jak w przypadku poprzedniej metody, tak i tutaj musimy zaimplementować limit prób wypełnienia formularza, ponieważ atakujący może próbować zastosować atak siłowy na pole z odpowiedzią. Sprawdzenie wszystkich możliwości dla pytania “Twój ulubionych kolor?” nie jest trudne, szczególnie gdy mamy do czynienia z przeciętnym mężczyzną, który umie ich nazwać osiem.

Czy chcesz wylogować wszystkie swoje sesje?

Załóżmy, że hasło zostało zmienione. To nie koniec potencjalnych problemów. Warto zadać sobie pytanie, dlaczego użytkownik skorzystał z funkcji przypominania hasła? Oczywiście, najprostsza odpowiedź brzmi “bo zapomniał hasła”, ale istnieje jeszcze drugi przypadek. Co jeśli ktoś przejął konto użytkownika i właśnie prawowity właściciel walczy o jego odzyskanie, a włamywacz dalej jest na to konto stale zalogowany?

Po zmianie hasła powinniśmy zapytać użytkownika, czy życzy sobie, aby unieważnić wszelkie zalogowane na jego konto sesje. Jeśli właściciel konta odpowie twierdząco, włamywacz straci sesję.

Czas się zalogować

Zmieniliśmy hasło, pozbyliśmy się zalogowanego atakującego, więc czas, aby użytkownik zalogował się na konto i znów spokojnie z niego korzystał. Wielu programistów decyduje się, aby nie utrudniać życia użytkownikowi i po ustawieniu hasła po prostu zalogować go na konto. Brzmi to bardzo rozsądnie, ale może doprowadzić do powstania nowej luki.

Najbezpieczniejszym rozwiązaniem będzie przekierowanie użytkownika na klasyczny panel logowania, aby nie tworzyć oddzielnego mechanizmu uwierzytelniania dla sytuacji po resecie hasła. Każdy nowy mechanizm wejścia do systemu musi być odpowiednio zabezpieczany, testowany i uaktualniany. W skrajnym przypadku może zdarzyć się, że klasyczne okno logowania będzie miało inny profil bezpieczeństwa niż procedura logowania po resecie hasła, ponieważ programiści zapomnieli zaktualizować drugą ze ścieżek. Nie mnóżmy dróg wejścia do systemu – pozostawmy jedną.

Poinformuj użytkownika o zmianie hasła!

Do zamknięcia całego procesu brakuje nam już tylko jednego kroku. Poinformowania użytkownika o fakcie zmiany hasła. Można zadać pytanie, “ale w jakim celu? Przecież użytkownik chyba wie, co przed chwilą zrobił?”. Ale czy mamy pewność, że cała procedura została faktycznie wykonana przez użytkownika? Warto wysłać na adres mailowy przypisany do konta (i ewentualnie wszystkie pozostałe kanały komunikacji, jeśli takie są dostępne) informację o zmianie hasła.

Jeśli użytkownik nie wykonał tej operacji samodzielnie, a został zaatakowany, to będzie miał jeszcze szansę skontaktować się z pomocą techniczną aplikacji i zatrzymać kolejne akcje na swoim koncie.

Podsumowanie

W tym artykule omówiłem jeden – mogłoby się wydawać, prosty – mechanizm dostępny w aplikacji webowej. Temat nie został całkowicie wyczerpany, bo można tu jeszcze poruszyć np. kwestię wstrzykiwania nagłówków e-mailowych i przejmowanie wiadomości z linkiem do resetu hasła. Ale to może zostawmy na kolejne odcinki cyklu Poradnika Hackowania Webaplikacji, albo na wiadomość tylko dla subskrybentów naszego technicznego newslettera poświęconemu bezpieczeństwu webaplikacji (wink, wink ;) na który możesz się zapisać poniżej:

Wpisz adres e-mail:

Rozwiąż Captcha:

HP

Bez obaw, podanych e-maili nikomu nie przekazujemy i wykorzystamy je wyłącznie do przekazywania Ci treści związanych z cyberbezpieczeństwem. Jeśli lubisz czytać o RODO, kliknij tutaj.

Na przykładzie tylko tego jednego mechanizmu resetu hasła widać ile pomyłek może zaliczyć osoba implementująca lub projektującą taki system. A “standardowych” mechanizmów w typowej aplikacji mamy znacznie więcej i przy każdym czają się kolejne pułapki. Jeśli chcesz je wszystkie poznać i podnieść bezpieczeństwo swoich serwisów internetowych, to zapraszamy do udziału w naszym szkoleniu z Atakowania i Ochrony Aplikacji Webowych — w trakcie szkolenia większość czasu spędzamy przed labami, w ramach których nauczymy Cię jak wykrywać błędy bezpieczeństwa w webaplikacjach i jak najsensowniej je usuwać. Oto najbliższe terminy tego szkolenia: