klucz klienta w OAuth 2.0

95

Aby korzystać z Google Drive API, muszę grać z uwierzytelnianiem przy użyciu OAuth2.0. Mam kilka pytań na ten temat.

  1. Identyfikator klienta i klucz tajny klienta służą do identyfikacji mojej aplikacji. Ale muszą być zakodowane na stałe, jeśli jest to aplikacja kliencka. Tak więc każdy może zdekompilować moją aplikację i wyodrębnić ją z kodu źródłowego. Czy to oznacza, że ​​zła aplikacja może udawać dobrą aplikację, używając identyfikatora i tajnego identyfikatora klienta dobrej aplikacji? Czyli użytkownik pokazywałby ekran z prośbą o udzielenie pozwolenia na dobrą aplikację, mimo że w rzeczywistości jest o to pytana przez złą aplikację? Jeśli tak, co mam zrobić? A może właściwie nie powinienem się tym martwić?

  2. W aplikacji mobilnej możemy osadzić w naszej aplikacji podgląd sieciowy. A wyodrębnienie pola hasła w widoku internetowym jest łatwe, ponieważ aplikacja prosząca o pozwolenie jest w rzeczywistości „przeglądarką”. Czyli OAuth w aplikacji mobilnej nie ma takiej korzyści, że aplikacja kliencka nie ma dostępu do danych uwierzytelniających użytkownika dostawcy usług?

security  oauth  google-api  oauth-2.0 
— Niedźwiedź
źródło
2
Wydaje mi się również, że ludzie są zwykle podejrzliwi, gdy aplikacja prosi ich o podanie danych logowania na Facebooku, Twitterze, Dropbox lub innych. Wątpię, by wielu zwykłych ludzi przeczytało specyfikację OAuth i powie „Teraz jestem bezpieczny”, ale zamiast tego kierują się zdrowym rozsądkiem i generalnie nie używają aplikacji, którym nie ufają.
— Igor Čordaš
Naprawdę świetne pytanie zdecydowanie powinno mieć więcej punktów
— Shravan
możesz po prostu pobrać ClientId i sekret ze swojego serwera i zapisać je w pęku kluczy przy pierwszym udanym logowaniu, to wszystko
— Shravan
@Sharvan Mogę się mylić, ale myślę, że pęki kluczy są podatne na zrootowane telefony, więc Twój sekret klienta może zostać upubliczniony.
— chichilatte

Odpowiedzi:

16

Zacząłem pisać komentarz do twojego pytania, ale potem odkryłem, że jest za dużo do powiedzenia, więc oto moje poglądy na ten temat w odpowiedzi.

  1. Tak, istnieje realna możliwość i było kilka opartych na tym exploitów. Sugeruje się, aby nie utrzymywać aplikacji w tajemnicy w swojej aplikacji, jest nawet część specyfikacji, że aplikacje rozproszone nie powinny używać tego tokena. Teraz możesz zapytać, ale XYZ wymaga tego, aby działać. W takim przypadku nie implementują poprawnie specyfikacji i nie powinieneś A korzystać z tej usługi (mało prawdopodobne) lub B spróbować zabezpieczyć token przy użyciu pewnych metod zaciemniających, aby utrudnić znalezienie lub używanie serwera jako proxy.

    Na przykład w bibliotece Facebooka na Androida było kilka błędów, w których wyciekały tokeny do Logów, możesz dowiedzieć się więcej na ten temat tutaj http://attack-secure.com/all-your-facebook-access-tokens-are-belong -do-nas i tutaj https://www.youtube.com/watch?v=twyL7Uxe6sk . Podsumowując, zachowaj szczególną ostrożność podczas korzystania z bibliotek stron trzecich (w rzeczywistości zdrowy rozsądek, ale jeśli przejęcie tokenów jest Twoim dużym problemem, dodaj kolejny dodatek do ostrożności).

  2. Od dłuższego czasu narzekałem na temat punktu 2. Zrobiłem nawet pewne obejścia w moich aplikacjach, aby zmodyfikować strony zgody (na przykład zmienić powiększenie i projekt w celu dopasowania do aplikacji), ale nic nie powstrzymało mnie przed odczytaniem wartości z pól w widoku sieciowym z nazwą użytkownika i hasłem. Dlatego całkowicie zgadzam się z drugim punktem i uważam to za duży „błąd” w specyfikacji protokołu OAuth. Chodzi o to, że „aplikacja nie uzyskuje dostępu do danych uwierzytelniających użytkownika” w specyfikacji jest tylko marzeniem i daje użytkownikom fałszywe poczucie bezpieczeństwa… Myślę też, że ludzie są zwykle podejrzliwi, gdy aplikacja prosi ich o podanie danych logowania na Facebooku, Twitterze, Dropbox lub innych. Wątpię, by wielu zwykłych ludzi czytało specyfikację OAuth i mówiło „Teraz jestem bezpieczny”, ale zamiast tego kierują się zdrowym rozsądkiem i generalnie nie używają aplikacji, którym nie ufają.

— Igor Čordaš
źródło
3
Twój identyfikator klienta i klucz tajny klienta nie będą bezpieczne tylko dlatego, że opublikujesz je w tunelu SSL. Tak, są bardziej zabezpieczone przed atakami człowieka w środku. Jeśli użytkownik pośredniczy w wywołaniu HTTPs, może zaakceptować zły certyfikat i zobaczyć wszystko, co opublikujesz. Nawiasem mówiąc, jest to najłatwiejszy sposób na kradzież czyjegoś klucza klienta na urządzeniach mobilnych.
— EpicThreeDev,
5
Doceniam twój komentarz, ale nie mogę go w żaden sposób połączyć z moją odpowiedzią ... Czy mógłbyś wyjaśnić, dlaczego skomentowałeś moją odpowiedź, ponieważ wyraźnie stwierdziłem, że sekret klienta nie powinien być używany w aplikacjach rozproszonych, a inna kwestia była taka istnieją obejścia umożliwiające uzyskanie poświadczeń użytkownika w aplikacjach, nawet jeśli używają OAuth, więc użytkownicy powinni ufać dostawcy aplikacji, a nie OAuth.
— Igor Čordaš
Nie rozumiem też, co masz na myśli, mówiąc „Jeśli użytkownik pośredniczy w wywołaniu HTTPs”, tak, użytkownicy uzyskują dostęp do danych, które wysłali przy użyciu protokołu HTTPs i mogą swobodnie wykonywać połączenia proxy w dowolny sposób. Jak zrozumiałem, sugerujesz, że jest to całkiem niezła alternatywa dla demontażu aplikacji, aby uzyskać sekret, ale z drugiej strony nie powinieneś przede wszystkim wysyłać sekretu aplikacji.
— Igor Čordaš
Czyli w punkcie 1) zła aplikacja musi mieć dostęp do tego samego systemu i pobierać token dostępu / odświeżania z tego samego urządzenia?
— gauteh
Nie jest jasne, co w tym kontekście uznajesz za „ten sam system”. Aplikacja tworzy widok sieciowy, w którym wyświetlana jest strona potwierdzenia i może uzyskać dostęp do wszystkich danych w tym widoku (w tym plików cookie lub parametrów adresu URL hostujących token dostępu). W niektórych przypadkach możliwy jest również dostęp między aplikacjami, na przykład jeśli jedna aplikacja może uzyskać dostęp do innych dzienników aplikacji, może tam znaleźć token, jak wspomniano w przypadku błędu fb lib.
— Igor Čordaš
16

Miałem to samo pytanie, co pytanie 1 tutaj i przeprowadziłem niedawno pewne badania i doszedłem do wniosku, że nie należy utrzymywać „klienta w tajemnicy” w tajemnicy. Typ klientów, którzy nie zachowują poufności informacji o kliencie, jest określany jako „klient publiczny” w specyfikacji OAuth2. Poniższe fakty zapobiegają możliwości uzyskania przez osobę złośliwą kodu autoryzacji, a następnie tokenu dostępu.

1. Klient musi otrzymać kod autoryzacyjny bezpośrednio od użytkownika, a nie od serwisu

Nawet jeśli użytkownik wskaże usługę, której ufa klientowi, klient nie może uzyskać kodu autoryzacji z usługi po prostu pokazując identyfikator klienta i sekret klienta. Zamiast tego klient musi otrzymać kod autoryzacyjny bezpośrednio od użytkownika. (Zwykle odbywa się to przez przekierowanie adresu URL, o czym opowiem później). Tak więc w przypadku złośliwego klienta nie wystarczy znać identyfikator / sekret klienta, któremu zaufał użytkownik. Musi w jakiś sposób zaangażować lub sfałszować użytkownika, aby podał mu kod autoryzacji, co powinno być trudniejsze niż zwykła znajomość identyfikatora / tajemnicy klienta.

2. Adres URL przekierowania jest zarejestrowany z identyfikatorem / sekretem klienta

Załóżmy, że złośliwy klient w jakiś sposób zdołał zaangażować użytkownika i zmusić go do kliknięcia przycisku „Autoryzuj tę aplikację” na stronie usługi. Spowoduje to wywołanie odpowiedzi przekierowania adresu URL z usługi do przeglądarki użytkownika wraz z kodem autoryzacji. Następnie kod autoryzacyjny zostanie wysłany z przeglądarki użytkownika na adres URL przekierowania, a klient powinien nasłuchiwać adresu URL przekierowania, aby otrzymać kod autoryzacji. (Adresem URL przekierowania może być również localhost i doszedłem do wniosku, że jest to typowy sposób, w jaki „klient publiczny” otrzymuje kod autoryzacji). Ponieważ ten adres URL przekierowania jest zarejestrowany w usłudze z identyfikatorem / sekretem klienta, złośliwy klient nie mają sposób kontrolowania, gdzie jest przekazywany kod autoryzacji.

— hideaki
źródło
3
To obiecujące, czy masz na to jakieś referencje? Pocieszałaby wiedza.
— gauteh
1
Widziałem w dokumentach na Dysku, że w zainstalowanych aplikacjach klucz klienta nie jest tak naprawdę tajemnicą, ale nie wyjaśnili, dlaczego można go tam przechowywać. Twoje wyjaśnienie bardzo pomogło!
— Martin Spasov
1

Odpowiedź na drugie pytanie: interfejsy API Google ze względów bezpieczeństwa upoważniają do uwierzytelniania / logowania się w samej aplikacji (np. Przeglądanie stron internetowych jest niedozwolone) i musi być wykonywane poza aplikacją za pomocą przeglądarki, aby zapewnić większe bezpieczeństwo, co jest dokładniej wyjaśnione poniżej: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

— vj
źródło
przynajmniej jest to „naprawione” 3 lata po tym, jak o to zapytałem :)
— Niedźwiedź
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.