Dlaczego potrzebujemy bezpieczeństwa usługi REST, jeśli mamy HTTPS

13

Odnoszę się do tego doskonałego artykułu http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/, który mówi o amazonie, takim jak bezpieczeństwo usług internetowych. Jednak w zespole zadano mi pytanie, dlaczego potrzebujemy go, jeśli już używamy HTTPS. Nie byłem w stanie odpowiedzieć, ponieważ wydaje mi się, że mogą mieć rację, chociaż jelito mówi mi inaczej.

Czy są też miejsca przy świadczeniu usług REST, w których HTTPS może nie działać? Podobnie jak witryny innych firm?

Jeśli ktoś ma doświadczenie w zabezpieczaniu usług internetowych za pośrednictwem publicznych interwebów, proszę rzucić nieco światła na swoje doświadczenie.

Z góry dziękuję.

EDYCJA: Aby wyjaśnić, nie mówię o uwierzytelnieniu użytkownika, ale raczej o uwierzytelnieniu klienta. Uwierzytelnienie użytkownika można założyć jako zwykły tekst przez HTTPS + REST.

Martwię się, że nadal umożliwia to każdemu korzystanie z usługi internetowej bez mojego klienta, aby uzyskać do niej dostęp, ponieważ wszystko jest tekstem w formacie plai, chociaż przez HTTPS punkt końcowy klienta może nadal korzystać z mojej usługi internetowej bez aplikacji klienckiej.

rest

— Abhishek Dujari
źródło

3

Najlepiej nadaje się do security.stackexchange.com ?

— jweyrich

1

może masz rację, ale moje pytanie jest z całą pewnością związane.

13

Dlaczego musimy podać Gmailowi - lub jakiejkolwiek innej witrynie z kontami użytkowników - naszą nazwę użytkownika i hasło, jeśli już używa HTTPS? Odpowiedź jest taka sama jak odpowiedź na twoje pytanie.

HTTPS zapewnia przede wszystkim szyfrowane połączenie między serwerem a klientem.

Zaufanie związane z HTTPS opiera się na głównych urzędach certyfikacji, które są wstępnie zainstalowane w oprogramowaniu przeglądarki (jest to odpowiednik powiedzenia „Ufam urzędowi certyfikacji (np. VeriSign / Microsoft / itp.), Aby powiedzieć mi, komu mam zaufać”).

O ile serwer nie przyzna każdemu użytkownikowi certyfikatu , serwer nie będzie mógł ufać klientowi bez innej metody uwierzytelnienia.

— Matt Ball
źródło

przepraszam, że źle zrozumiałeś lub nie byłem jasny. Dokumenty Amazon APi stwierdzają, że powinniśmy używać HTTPS, ale jeśli nie, TO podpiszemy prośbę. W tym momencie hasło nazwy użytkownika nie ma znaczenia.

3

Na wysokim poziomie musisz udowodnić swoją tożsamość na serwerze, aby mógł on przyjmować polecenia od ciebie. Uwierzytelnianie klienta można wykonać za pomocą protokołu HTTPS, a także przy użyciu podpisywania wiadomości.

— Matt Ball

1

Jeśli chcesz używać HTTPS do uwierzytelniania klienta, musisz wydać każdemu użytkownikowi certyfikat klucza publicznego, jak opisano w ostatnim linku w mojej odpowiedzi. Pomyśl o tych certyfikatach jak o elektronicznej wersji paszportu.

— Matt Ball

1

Link do „daj każdemu użytkownikowi certyfikat”, odpowiedzi na moje pytanie. Wydaje mi się, że cały prywatny klucz publiczny i podpis jest nadal wymagany, aby odpowiednio zabezpieczyć oba końce usługi internetowej, więc SSL na serwerze nie wystarczy. Twoja odpowiedź jest jak dotąd najbliższa. Dziękuję Ci bardzo.

— Abhishek Dujari,

1

+1 Wspaniale jest wspominać certyfikaty klienta, ale serwer nie musi wydawać certyfikatów. Muszą tylko zostać podpisane przez zaufany urząd certyfikacji; w zasadzie to samo, co działają certyfikaty serwera.

— JimmyJames

3

HTTPS jest bardzo dobry w zapobieganiu podsłuchom i atakom typu „człowiek w środku”. Ponieważ szyfruje cały ruch dla sesji.

Ponieważ jednak większość osób korzysta z domyślnych certyfikatów dostarczonych z przeglądarką i nie ma pojęcia, jak utworzyć własny certyfikat osobisty lub skonfigurować przeglądarkę, aby z niego korzystał.

To sprawia, że HTTPS jest całkiem bezużyteczny do uwierzytelniania użytkowników innych niż ochrona okna dialogowego uwierzytelniania przed podsłuchem itp.

— James Anderson
źródło

Myślę, że jesteś bardzo blisko tego, o co proszę. Więc sugerujesz, że powinniśmy podpisać żądanie po stronie klienta, nawet jeśli używamy HTTPS?

2

HTTPS polega na zabezpieczeniu kanału, nie udowadnianiu, kto dzwoni, ani wielu innych rzeczach, które należy wziąć pod uwagę. Uwierzytelnianie, autoryzacja i szyfrowanie warstwy transportowej to tylko niewielka część tego, co należy wziąć pod uwagę. Wiele znanych luk w zabezpieczeniach związanych z aplikacjami sieciowymi ma bardzo duże zastosowanie do apli REST. Musisz wziąć pod uwagę sprawdzanie poprawności danych wejściowych, łamanie sesji, nieodpowiednie komunikaty o błędach, wewnętrzne luki w zabezpieczeniach pracowników i tak dalej. To duży temat.

Robert

— Robert Morschel
źródło

0

Możesz zastosować podejście do certyfikatów SSL klienta i oddzielić zabezpieczenia od interfejsu API. Dużym minusem tego podejścia jest narzut operacyjny, który będzie kosztowny, ponieważ coraz więcej klientów korzysta z interfejsu API.

W każdym razie podstawowe uwierzytelnianie HTTP jest w porządku dla zdecydowanej większości usług publicznych.

— CodeToGlory
źródło