Ten artykuł zajmie się dobrze znanymi lukami Oauth. Czytelnicy dowiedzą się również, jak wdrażać bezpieczne i bezpieczne autoryzacja w aplikacji internetowej.
Oauth jest niezawodnym protokołem, ale jego stopień bezpieczeństwa w dużej mierze zależy od świadomości programistów internetowych przy wdrażaniu autoryzacji. To sprawia, że ten temat jest niezwykle ważny dla specjalistów bezpieczeństwa informacji. Muszą zapewnić wysoki poziom ochrony kont swoich użytkowników. Nadszedł czas, aby zapoznać się z skutecznymi praktykami, którzy pomogą zmniejszyć niebezpieczeństwo słabej sprzedaży Oauth.
WprowadzenieProtokół OAUTH 2.0 jest obecnie szeroko stosowany w różnych zastosowaniach. Korzystając z niego, wygodny interfejs użytkownika staje się dostępny, łatwiejsze uwierzytelnianie i autoryzacja w porównaniu do tradycyjnych metod wprowadzania nazwy użytkownika i hasła. Dzięki odpowiednim i przemyślanym wdrożeniu protokół OAUTH będzie bezpieczniejszy niż tradycyjne autoryzacja, ponieważ użytkownicy nie muszą dzielić się swoimi danymi księgowymi z aplikacją innych firm, aby uzyskać dostęp do określonego zasobu. Użytkownicy często wolą logować przy użyciu swoich kont Google, Facebook lub LinkedIn, zamiast tworzyć nowe konto za każdym razem, gdy musisz zarejestrować się na stronie internetowej. W ten sposób protokół OAUTH znacznie upraszcza nasze życie.
Ogólnie rzecz biorąc, popularni dostawcy usług Oauth są bardzo niezawodni. Zaloguj się za pomocą konta Google lub Facebook inspiruje pewne poczucie bezpieczeństwa i jest poprawne. Protokół jest starannie przetestowany przez ekspertów. Wszystkie dostępne luki są zawsze szybko skorygowane przez zespół deweloperski. Warto jednak zauważyć, że poczucie pełnego bezpieczeństwa może być fałszywe.
Dostawcy usług Oauth pozostawili deweloperzy aplikacji wiele powodów, aby twierdzić bezpieczeństwo swoich programów. W rzeczywistości początkowo chroniona usługa Oauth, nieprawidłowo wdrażana w procesie jego instalacji, może stać się łatwym celem dla intruzów. Takie przygotowawstwo doprowadzi do kradzieży danych osobowych użytkowników.
Następnie należy wziąć pod uwagę najczęstsze luki napotykane w aplikacjach innych firm, które wdrażają protokół OAuth, aby autoryzować ich użytkowników. Należy pamiętać, że sam protokół jest bezpieczny i niezawodny. Dopiero po nieprawidłowym wdrożeniu staje się podatny na ataki hakerów.
Kradzież oauth tokey za pomocą nagłówka referencjiGdy żądanie wniosku o zezwolenie w imieniu użytkownika na serwerze OAUTH, osoba otrzymuje kod do wprowadzania i wysyłania z powrotem do serwera, aby uzyskać kolejną kontrolę. Jeśli podczas pracy użytkownik zostanie przekierowany na inną stronę, kod zostanie postrzegany w nagłówka "referencji" żądania HTTP. W ten sposób kod spadnie na zewnętrznej stronie internetowej, która zagraża danych użytkownika zarejestrowanym na serwerze OAuth.
Uwaga: Nagłówek referencyjny jest nagłówkiem zapytania HTTP, przesyła hosta URL, z którego wysyłany jest żądanie.
Aby zmiękczyć konsekwencje tej luki, deweloper musi upewnić się, że jego aplikacja internetowa nie zawiera żadnych zastrzyków HTML. Jeśli wykryto zastrzyki, atakujący może łatwo ustawić znacznik obrazu na swój serwer WWW i znajdź sposób na przekierowanie użytkownika na nim. Tak więc będzie miał okazję ukraść kod z nagłówka "referencji" żądania HTTP.
Kradzież oauth tokey za pomocą parametru Redirect_uriAplikacja inicjuje proces autoryzacji, wysyłając żądanie do serwera OAuth:
https://www.example.com/signin/authorize?[...]&redirect_uri=httpps://demo.example.com/loginsuccessful.
Zapytanie zawsze zawiera parametr "Redirect_uri" używany przez serwer OAuth, aby wysłać żetony z powrotem do aplikacji po tym, jak użytkownik wyraził zgodę. Jeśli wartość tego parametru nie jest kontrolowana lub nie jest zaznaczona, atakujący może łatwo zmienić go i przekierować żądanie na swoją stronę internetową, gdzie używa specjalnego programu do przetwarzania tokena i uzyskać dostęp do ograniczonego zasobu.
https://www.example.com/signin/authorize?[...]&redirect_uri=httpps://localhost.evil.com.
Czasami podobne adresy URL są zablokowane. Atakujący może przekierować otrzymane dane na otwartym adresie URL, tak jak:
https://www.example.com/oauth20_authorize.srf?[...[&redirect_uri=httpps://accounts.google.com/backtooouthsubtarget?nastel =httpset://evil.com.
Albo to:
https://www.example.com/oauth2/authorize? [...]% Irect_uri = https% 3a% 2F% 2fapps.Facebook.com% 2fatacker% 2F.
Podczas wdrażania Outh nigdy nie można zawierać całe domen na białej liście. Do "Redirect_uri" należy dodać tylko kilka adresów URL, nie przekierowano prośby o otwarcie przekierowania.
Fałszerstwo żądań krzyżowychFałasowanie prośby pośrodku może wystąpić, gdy atakujący uda się udaje ci ofiarę, aby kliknąć na jego link, a zatem wygenerować prośbę, że nie będzie generować. Fałasowanie żądań krzyżowych jest zwykle zmiękczone token CSRF, który jest powiązany z sesją użytkownika. Pomaga aplikacji sprawdzić osobę osoby, która wysłała prośbę. Parametr "State" w protokole OAUTH służy jako token CSRF.
Warto zobaczyć, w jaki sposób atak CSRF jest przeprowadzany na Oauth i jako parametr "Stanowy" można wykorzystać do złagodzenia wpływu podatności.
Hacker otwiera aplikację internetową i uruchomi proces autoryzacji, aby uzyskać dostęp do usługodawcy za pomocą OAUTH. Aplikacja żąda dostawcy usług do uzyskania dostępu do zapewnienia. Haker zostanie przekierowany do strony internetowej Usługodawcy, gdzie zazwyczaj musisz wprowadzić swoją nazwę użytkownika i hasło, aby autoryzować dostęp. Zamiast tego haker łapie i uniemożliwia to żądanie i zapisuje swój adres URL. Haker w jakiś sposób powoduje, że ofiara otworzy ten adres URL. Jeśli ofiara wprowadziła system usługodawcy za pomocą swojego konta, jego poświadczenia zostaną wykorzystane do wydania kodu autoryzacji. Kod autoryzacji wymiana dostępu do tokenu dostępu. Teraz konto Hacker w aplikacji jest autoryzowane. Może uzyskać dostęp do konta ofiary.
Jak więc mogę zapobiec tej sytuacji za pomocą parametru "stan"?
Aplikacja musi utworzyć wartość, która jest w jakiś sposób na podstawie konta źródłowego (na przykład, użyj klawisza Hash Session Session). To nie jest tak ważne, co to jest, głównym rzeczą jest to, że wartość jest wyjątkowa i generowana przy użyciu prywatnych informacji o oryginalnym użytkowniku. Jest przypisany do parametru "stanu".
Wartość ta jest przesyłana do usługodawcy podczas przekierowania. Teraz haker zaprasza ofiarę, aby otworzyć adres URL, który zachował.
Kod autoryzacji jest wydawany i odesłany do klienta w sesji wraz z parametrem "stan".
Klient generuje wartość parametru na podstawie informacji o sesji i porównuje go z wartością "State", która została odesłana z żądania autoryzacji do usługodawcy. Ta wartość nie pasuje do parametru "stanu" w zapytaniu, ponieważ została wygenerowana tylko na podstawie informacji o bieżącej sesji. W rezultacie otrzymana wartość nie jest akceptowana przez system.
Inne luki wykryte podczas implementacji Oauth obejmują możliwość wykonania XSS (skryptowanie poprzeczne) za pomocą parametru "Redirect_uri", ustawienie klucza prywatnego OAUTH (klucz może być czasami uzyskany podczas dekompilowania aplikacji mobilnej) i naruszenie kodu z autoryzacją (kiedy Kod autoryzacji można użyć więcej niż raz, aby wydać wiele żetonów dostępu). Te luki są mniej powszechne niż opisane powyżej, ale nie uczyni ich mniej niebezpiecznymi. Deweloper powinien znać wszystkie niezbędne praktyki, aby zapewnić niezawodne działanie swojej aplikacji internetowej.
Autor przetłumaczonego artykułu: Simon Saliba.
Ważny! Informacje wyłącznie do celów akademickich. Proszę przestrzegać prawodawstwa i nie stosować tych informacji dla nielegalnych celów.
Bardziej interesujący materiał na cisoclub.ru. Subskrybuj nam: Facebook | Vk |. Twitter |. Instagram |. Telegram |. Zen |. Messenger |. ICQ Nowy |. YouTube |. Puls.