Czy protokół OAuth2 i protokół SSL wystarczą do zabezpieczenia interfejsu API

Question

Próbuję znaleźć najlepszy sposób zabezpieczenia interfejsu API. Dopuszczam tylko protokół SSL i używam OAuth2 do uwierzytelniania, ale to nie wydaje się wystarczające.

Największy problem, jaki mam, polega na tym, że każdy może sprawdzać, czy wnioski są przesyłane przez uprawnionego klienta do interfejsu API i kradną identyfikator klienta OAuth. W tym momencie będą mogli skonstruować dowolne żądanie, aby podszyć się pod prawowitego klienta.

Czy istnieje sposób, aby temu zapobiec? Widziałem ludzi używają HMAC hash parametrów przy użyciu tajnego klucza znanego tylko klientowi i serwerowi, ale widzę 2 problemy z tym.

1. To bardzo trudne (niemożliwe?), Aby uniemożliwić złośliwemu użytkownikowi dekompilowanie klienta i wykrycie tajnego klucza.
2. Niektóre parametry wydają się dziwne, aby uzyskać skrót HMAC. Na przykład, jeśli parametr był bajtami pliku, czy uwzględniłeś całą rzecz w haszowaniu HMAC?

Answer 1

Można wdrożyć wzajemnie uwierzytelniony protokół SSL między prawowitymi klientami a interfejsem API. Wygeneruj samopodpisany certyfikat klienta SSL i zapisz go w swoim kliencie. Skonfiguruj serwer tak, aby wymagał uwierzytelniania po stronie klienta i akceptuj tylko te certyfikaty, które wdrożyłeś na swoich klientach. Jeśli ktoś/coś próbujące się połączyć nie ma tego certyfikatu klienta, nie będzie mógł ustanowić sesji SSL i połączenie nie zostanie nawiązane. Zakładając, że kontrolujesz legalnych klientów i serwery, nie potrzebujesz tutaj certyfikatu wystawionego przez CA; po prostu używaj certyfikatów z podpisem własnym, ponieważ kontrolujesz zarówno zaufanie po stronie klienta, jak i po stronie serwera.

Teraz mówisz, że naprawdę trudno jest uniemożliwić komuś odwrócenie inżynierii klienta i odzyskanie poświadczeń (klucz prywatny należący do certyfikatu klienta, w tym przypadku). I masz rację. Normalnie przechowujesz ten klucz (i certyfikat) w magazynie kluczy czegoś (KeyStore, jeśli używasz Androida) i ten magazyn kluczy zostanie zaszyfrowany. Szyfrowanie jest oparte na haśle, więc musisz albo (1) przechowywać to hasło w swoim kliencie, albo (2) zapytać użytkownika o hasło podczas uruchamiania aplikacji klienckiej. To, co musisz zrobić, zależy od Twojego zastosowania. Jeśli (2) jest akceptowalne, chroniłeś swoje referencje przed inżynierią wsteczną, ponieważ będzie ona zaszyfrowana, a hasło nie będzie przechowywane nigdzie (ale użytkownik będzie musiał wpisać to za każdym razem). Jeśli to zrobisz (1), wtedy ktoś będzie mógł wykonać inżynierię wsteczną, uzyskać hasło, pobrać magazyn kluczy, odszyfrować klucz prywatny i certyfikat oraz utworzyć kolejnego klienta, który będzie mógł połączyć się z serwerem.

Nic nie możesz zrobić, aby temu zapobiec; możesz sprawić, że inżynieria odwrotna będzie ciężej (przez zaciemnianie, itp.), ale nie możesz uniemożliwić.Musisz określić, jakie ryzyko próbujesz złagodzić za pomocą tych metod i ile pracy warto wykonać, aby je złagodzić.

Answer 2

Czy używasz kroku uwierzytelniania OAuth przy użyciu samego protokołu SSL? To zapobiega wszelkim metodom szpiegowania, ale oznacza to, że musisz zachować ostrożność, aby certyfikat serwera OAuth był aktualny. (Uwaga, serwer OAuth może mieć tożsamość SSL publicznego; to wciąż nie do podrobienia ze nawet niejasno rozsądnych ilościach wysiłku To tylko klucz prywatny, który musi być utrzymywane w tajemnicy.).

Powiedział, że cię musicie być bardziej ostrożni, przed czym chronicie. Dlaczego ludzie muszą w ogóle używać twojego kodu klienta? Dlaczego to musi być "tajne"? Łatwiej to oddać i umieścić na swoim serwerze spryt (w tym weryfikację tożsamości logowania). Jeśli ktoś chce napisać własnego klienta, pozwól mu. Jeśli ktoś chce publicznie machnąć swoim kontem w głupi sposób, obciążyć ich kosztami, które ponoszą ze swojej głupoty ...