14-02-2019 / Owasp

[OWASP Top 10] A2

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.

Logowanie

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.

Logowanie kontem

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.

Ustawienia widoczności

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.
Długość hasła
https://howsecureismypassword.net/

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.

Menadżery haseł

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.

Sól do hasła

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.

Pytania do konta

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.

reCAPTCHA

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 reCAPTCHA2.

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.

Dwuskładnikowe uwierzytelnienie

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

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.

Zapamiętaj mnie
https://freepik.com

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?

Wylogowywanie
https://freepik.com

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