Cześć!
Witam Cię w drugim odcinku z serii OWASP Top 10, w której tłumaczę najpopularniejsze błędy bezpieczeństwa powiązane z serwisami internetowymi.
Dzisiaj o drugiej kategorii - Broken authentication
a tłumacząc to na polski: o niepoprawnej obsłudze uwierzytelniania.
W tej kategorii znajdują się wszystkie błędy powiązane z funkcjonalnością logowania oraz sprawdzania uprawnień użytkownika.
Możesz sobie pomyśleć, że przecież tego nie może być dużo - wszak to tylko formularz z polem na login oraz hasło.
Rzeczywistość jest jednak zupełnie inna.
Weźmy pod lupę serwis Facebook.
Każdy może się tam zalogować przy użyciu loginu i hasła. Do logowania można jednak użyć numeru telefonu.
Logować można się z poziomu urządzeń mobilnych i różnych aplikacji.
Facebook pozwala na logowanie się również do innych serwisów - przy pomocy panelu logowania tej platformy.
Nasze dane mogą pobierać inne aplikacje lub gry - jeżeli nadaliśmy im odpowiednie uprawnienia.
Każdy z nas może należeć do różnych grup i pełnić w nich różne funkcje.
Jeden jest administratorem a drugi zwykłym użytkownikiem.
Każdy post może mieć nadane różne opcje widoczności - dzięki temu możemy dokładnie określić kto może go widzieć.
A to tylko kropla w morzu funkcjonalności tego internetowego giganta.
A każda z tych funkcjonalności sprawdza, czy podany użytkownik ma uprawnienia do danego zasobu.
Im bardziej zaawansowany serwis tym więcej miejsc, w których można popełnić błąd.
Wyobraź sobie chociażby, że nagle dostajesz uprawnienie administratora w całym serwisie i możesz przeglądać i usuwać wszystko i wszędzie.
Rzeczy powiązanych z uprawnieniami jest zatem dużo więcej niż mogło by się na pierwszy rzut oka wydawać.
Zaczynajmy!
Zacznijmy od rejestracji - bo przecież zanim użytkownik będzie mógł się zalogować do naszego serwisu musi stworzyć w nim konto.
A tutaj trzeba zacząć od rzeczy najprostszych.
- Po pierwsze wymuszanie odpowiedniej długości hasła.
Kilka znaków to dzisiaj minimum, konta z jednocyfrowymi hasłami to idealne pole do nadużyć.
W zależności od rodzaju serwisu możemy pokusić się o sprawdzanie najpopularniejszych haseł.
Te powiązane z religią, testowaniem czy też psem i kotem to nie najlepszy pomysł.
Niektóre serwisy ograniczają maksymalną długość hasła oraz znaki, które mogą się w nim znajdować.
A przecież sporo z dzisiejszych użytkowników korzysta z menadżerów haseł1 i rzadko kiedy wpisuje je manualnie.
Więc twierdzenie, że to tylko dla wygody użytkowników mija się z prawdą.
A takie obostrzenia mogą prowadzić do pytań.
Czy dany serwis przechowuje takie hasła w postaci plain textu - czyli bez żadnego hashowania?
Hasło użytkownika nigdy nie powinno być zapisywane na serwerze w taki sposób.
Warto również zatroszczyć się o logi - aby również tam nigdy się nie pojawiało.
Hasła warto przechowywać w postaci haszy - czyli z wykorzystaniem algorytmów jednostronnych - gdzie długi ciąg znaków jest matematycznie przekształcany na inny - o stałej długości.
I co najważniejsze tej operacji nie da się odwrócić - to znaczy nie da się odzyskać hasła posiadając jedynie jego hasz.
Przyjmując najgorszy scenariusz, kiedy to baza z hasłami użytkowników znajdzie się w rękach przestępców, przydatnym może być użycie dodatkowej soli.
Sól to losowy ciąg znaków, generowany dla każdego użytkownika z osobna.
Ten to ciąg jest łączony z hasłem użytkownika i dopiero wtedy wyliczany jest hasz hasła.
Dzięki temu, jeżeli baza wycieknie - hasło każdego użytkownika będzie musiało być łamane osobno.
Ponieważ każdy użytkownik ma inną sól - więc każde hasło zaczyna się od innych liter.
Dla dwóch użytkowników to samo hasło będzie miało inną wartość hasza.
Dla pierwszego będzie to sól1pies
a dla drugiego sól2kot
.
Pozostają na etapie rejestracji, warto zastanowić się ile kont można założyć z podanego adresu IP.
Oprócz haseł użytkownika można dopytać o dodatkowe dane, tak zwane pytania bezpieczeństwa.
Teoretycznie mają one uprościć procedurę przywracania hasła jeżeli użytkownik go zapomni.
Tylko że takie pytania bywają tendencyjne.
Jeżeli serwis pyta o imię matki, nasze przezwisko w szkole czy też datę urodzenia naszego brata - większość tych danych można pozyskać po prostu używając wyszukiwarki Google.
Również możliwość samodzielnego ustalania takich pytań bywa myląca.
Ludzie mają bowiem tendencję do wpisywania rzeczy prostych.
A słabe pytania i odpowiedzi mogą posłużyć do przejęcia konta przy pomocy formularza resetowania konta.
Sam proces przywracania dostępu do konta należy dokładnie sprawdzić.
Jak on działa? Czy użytkownik otrzymuje email z linkiem do przywracania hasła?
Czy zmieniając parametr w takim linku możliwa jest zmiana hasła innego użytkownika.
Czy token
wysłany w treści emaila jest generowany losowo - a może opiera się na jakimś schemacie?
Może to zakodowany algorytmem base64 identyfikator użytkownika?
A może serwis po prostu wysyła stare hasło na maila?
Co, jak opisywałem wcześniej, nigdy nie jest dobre.
Posiadając już konto można się na nie zalogować.
A tutaj warto pomyśleć o mechanizmach mających chronić przed atakami bruteforce
.
To znaczy - po kilku błędnych próbach logowania z danego adresu IP blokować możliwość logowania na kilka minut.
Popularne są ataki Credential Stuffing
kiedy to atakujący próbuje różnych kombinacji loginów i haseł, które zazwyczaj pochodzą z innych wycieków danych – w taki sposób próbując znaleźć konta tych samych użytkowników na naszej witrynie.
Innym sposobem może być dodanie captcha
- czyli obrazka z losowymi literami i cyframi, którego treść użytkownik musi przepisać aby jego żądanie było obsłużone.
Oczywiście istnieją automatycznie narzędzia rozpoznawające tekst z obrazków, ale lepsze takie zabezpieczenie niż żadne.
Można również skorzystać z zewnętrznych usług tego rodzaju, chociażby reCAPTCHA
2.
Tworząc aplikacje zdarza się, że tworzymy tak zwane konta deweloperskie, które podczas prototypowania aplikacji służą nam do szybkiego logowania się.
Chodzi tu zatem o słynne kombinacje admin/admin
czy test/test
.
Warto sprawdzić czy te konta zostały usunięte z produkcyjnej wersji aplikacji.
Phishing to najpopularniejsza metoda wykradania danych użytkownika.
Założenie jest proste - atakujący tworzy kopię danego serwisu, a następnie wysyła do ofiary odpowiednio spreparowany link.
Jeżeli atakowany nie zauważy, że wpisuje dane na innej stronie niż oficjalna - atakujący uzyskuje do nich dostęp.
Stąd też coraz popularniejszym jest implementowanie dwuskładnikowego uwierzytelnienia3 - kiedy to po weryfikacji hasła użytkownik musi wykonać dodatkową akcję.
Istnieją różne metody: sprzętowy token, kod z smsa czy też wiadomości email.
Jeżeli witryna udostępnia taką funkcjonalność warto sprawdzić czy ją respektuje.
A może da się ominąć ten mechanizm i zalogować się bez dwuskładnikowego uwierzytelnienia?
Obecnie aplikacje to nie tylko strony internetowe, ale również wszelakiego rodzaju serwisy API.
Może któryś z endpointów API, udostępniany dla specyficznej, starej aplikacji, nie wspiera tego dodatkowego mechanizmu?
Po zalogowaniu serwer musi jakoś wiedzieć, że my to my - tak abyśmy nie musieli za każdym razem na nowo przesyłać w każdym żądaniu loginu i hasła.
Musi posiadać możliwość identyfikacji danego użytkownika – a to jest możliwe za pomocą identyfikatorów sesji.
Mogą być one dodawane do adresu URL, ale to umożliwia podglądnięcie ich przez osoby postronne.
Dlatego lepszą metodą jest używanie ciasteczek.
Ciasteczka - czyli małe pliki na dysku, których zawartość przesyłana jest z każdym żądaniem.
W nich to znajduje się identyfikator sesji jednoznacznie wskazujący na użytkownika.
Jak wygląda ten identyfikator? Czy jest to losowo wygenerowana wartość? A może liczba, która z każdym logowaniem zwiększa się o 1?
A może to po prostu adres email? Co stanie się gdy zmienimy wartość takiego ciasteczka?
Czy zostaniemy zalogowani jako inny użytkownik?
Ciasteczka mają też minusy.
Ich treść można odczytywać z poziomu kodu JavaScript a ponieważ zawierają one wszystkie informacje potrzebne do zalogowania się jako bieżący użytkownik - jeżeli atakujący, jest w stanie je przejąć 9na przykład przy pomocy ataku XSS, który będzie opisywany w kolejnej części tej serii) to może użyć takiego ciasteczka w ataku pass the cookie
i zalogować się przy jego pomocy na konto atakowanego użytkownika.
A to wszystko bez znajomości jego loginu i hasła.
Dlatego też warto rozważyć ustawienia atrybutów httponly
dla ciasteczek powiązanych z sesją użytkownika.
Dzięki temu ich treść nie jest widoczna z poziomu kodu JavaScript.
Ciasteczka mogą również służyć do innych celów, na przykład do obsługi funkcji Zapamiętaj mnie
.
Znamy ją z większości serwisów społecznościowych. Po co logować się do nich za każdym razem gdy uruchamiamy przeglądarkę?
Przecież i tak z naszego komputera korzystamy tylko my. Po co utrudniać sobie życie.
Do przechowywania tych danych służą odpowiednie algorytmy i przechowywanie hasła użytkownika w takim ciasteczku nie jest dobrym pomysłem.
Często pozwalamy na modyfikację danych użytkownika, chociażby na zmianę adresu email.
W panelu administratora zazwyczaj istnieje opcja zmiany typu konta ze zwykłego na takie z podniesionym uprawnieniami.
O ile pamiętamy aby podczas rejestracji blokować próby stworzenia konta z wyższymi możliwościami, to czy pamiętamy o tym również w formularzu edycji danych użytkownika?
Na koniec pracy każdy powinien się wylogować, czyli sprawić że jego sesja wygaśnie i nie będzie możliwe jej ponowne użycie.
Ale czy ten mechanizm rzeczywiście działa?
A może strona jedynie usuwa odpowiednie ciasteczka użytkownika, a nie usuwa ich po stronie serwera?
Wtedy jeżeli atakujący posiada dostęp do starych ciasteczek - dalej może zalogować się na konto użytkownika.
Jak długo sesja jest ważna, jeżeli użytkownik z niej nie korzysta? Czy kiedykolwiek wygasa?
Jak widzisz logowanie to wieloetapowy proces i na każdym jego kroku można popełnić błąd.
Zapraszam Cię do kolejnego odcinka z serii OWASP Top 10, o ekspozycji wrażliwych danych czyli o wydobyciu przez atakującego informacji, których nie powinien posiadać.
Free Broll provided by videezy.com Stock footage provided by Videvo, downloaded from https://www.videvo.net
Icon made by Freepik www.flaticon.com
Design vector created by freepik - www.freepik.com