Najlepsze praktyki dotyczące zabezpieczania interfejsu API / usługi REST [zamknięty]

828

Czy podczas projektowania interfejsu API lub usługi REST istnieją sprawdzone metody postępowania z bezpieczeństwem (uwierzytelnianie, autoryzacja, zarządzanie tożsamością)?

Podczas budowania interfejsu API SOAP masz WS-Security jako przewodnik i dużo literatury na ten temat. Znalazłem mniej informacji o zabezpieczaniu punktów końcowych REST.

Chociaż rozumiem, że REST celowo nie ma specyfikacji analogicznych do WS- *, mam nadzieję, że pojawiły się najlepsze praktyki lub zalecane wzorce.

Wszelkie dyskusje lub linki do odpowiednich dokumentów będą mile widziane. Jeśli ma to znaczenie, używamy WCF z serializowanymi komunikatami POX / JSON dla naszych interfejsów API / usług REST zbudowanych przy użyciu wersji 3.5 .NET Framework.

Nathan
źródło
1
czy znasz jakąkolwiek pełną prawdziwą aplikację korzystającą z dobrych wzorców i praktyk z REST API i webServices w github?
PreguntonCojoneroCabrón

Odpowiedzi:

298

Jak powiedział tweakt, Amazon S3 jest dobrym modelem do pracy. Ich podpisy mają pewne funkcje (takie jak włączenie znacznika czasu), które chronią przed przypadkowym i złośliwym odtwarzaniem żądań.

Zaletą HTTP Basic jest to, że obsługują go praktycznie wszystkie biblioteki HTTP. Będziesz oczywiście musiał wymagać SSL w tym przypadku, ponieważ wysyłanie haseł w postaci zwykłego tekstu przez sieć jest prawie złą rzeczą. Podstawowy jest lepszy niż Digest przy korzystaniu z SSL, ponieważ nawet jeśli dzwoniący już wie, że wymagane są poświadczenia, Digest wymaga dodatkowej podróży w obie strony, aby wymienić wartość nonce. W przypadku Basic osoby dzwoniące po prostu wysyłają poświadczenia za pierwszym razem.

Po ustaleniu tożsamości klienta autoryzacja jest tak naprawdę tylko problemem związanym z wdrożeniem. Można jednak delegować autoryzację do innego komponentu z istniejącym modelem autoryzacji. Znowu fajną rzeczą w Basic jest to, że twój serwer kończy się zwykłym tekstem hasła klienta, które możesz po prostu przekazać w razie potrzeby innemu komponentowi w swojej infrastrukturze.

Greg Hewgill
źródło
3
SSL jest ważną częścią bezpieczeństwa, ale nie wszystkie aplikacje wymagają takiego poziomu szyfrowania. Jeśli ktoś kradnie w tranzycie to, co zamierzasz opublikować publicznie na Twitterze, czy to taka znacząca wada? W przypadku większości interfejsów API preferowane będzie szyfrowanie SSL. Wymagania infrastrukturalne dotyczące protokołu SSL są nieco wyższe niż w przypadku zwykłego tekstu i żadne pośrednie (buforowane) serwery buforujące nie mogą brać udziału w buforowaniu treści, do których wielokrotnie uzyskiwano dostęp. Uwaga, skalowalność może ucierpieć, jeśli absolutnie potrzebujesz oferowanego szyfrowania.
Norman H
36
@NormanH: Twój argument jest podstępny, ponieważ jeśli ktoś może zobaczyć całą transakcję, której używam do publikowania na Twitterze, może podszyć się pode mnie i opublikować własne wiadomości pod moim imieniem.
Greg Hewgill
3
Cytując z wikipedii o uwierzytelnianiu szyfrowanym, „Uwierzytelnianie dostępu szyfrowanego jest jedną z uzgodnionych metod, których serwer internetowy może używać do negocjowania poświadczeń w przeglądarce internetowej użytkownika. Stosuje funkcję skrótu do hasła przed wysłaniem go przez sieć, która jest bezpieczniejsze niż podstawowe uwierzytelnianie dostępu, które wysyła zwykły tekst ”. co byłoby jednym standardowym sposobem osiągnięcia tego, o czym wspomniałem powyżej. (Szczegółowe informacje można znaleźć na en.wikipedia.org/wiki/Digest_access_authentication )
Norman H
5
"sending plaintext passwords over the net is almost universally a bad thing"- Czy potrafisz rozwinąć „prawie”? Kiedy to nie jest zły pomysł?
toniedzwiedz
2
@GregHewgill nawet w sieci prywatnej nie chciałbym, aby moi użytkownicy mogli przechwytywać hasła innych użytkowników. Jedyną możliwą sytuacją, w której mogę przesłać hasło przez sieć, jest sytuacja, gdy użytkownik jest sam w sieci. Fakt, że takie rzeczy dzieją się gdzie indziej, nie jest powodem, aby na to pozwolić.
toniedzwiedz
115

Nie ma żadnych standardów REST innych niż HTTP. Tam są ustanowione usługi REST. Proponuję rzucić okiem na nie i przekonać się, jak działają.

Na przykład pożyczyliśmy wiele pomysłów z usługi Amazon REST S3 podczas opracowywania własnej. Ale zdecydowaliśmy się nie używać bardziej zaawansowanego modelu bezpieczeństwa opartego na sygnaturach żądań. Prostszym podejściem jest uwierzytelnianie HTTP Basic przez SSL. Musisz zdecydować, co będzie najlepsze w twojej sytuacji.

Również bardzo polecam książkę RESTful Web Services od O'reilly. Wyjaśnia podstawowe pojęcia i zapewnia najlepsze praktyki. Zasadniczo możesz wziąć dostarczony przez siebie model i zamapować go na własną aplikację.

Mark Renouf
źródło
6
RESTful Web Services to zdecydowanie świetna książka. Trzeba przeczytać w tym obszarze. To było wręcz inspirujące.
EdgarVerona
6
Jak to się stało, że @aehlke otrzymało tak wiele pozytywnych opinii na ten komentarz, biorąc pod uwagę (1), że nie ma czegoś takiego jak specyfikacja REST i (2) rozprawa polowa na temat stylów architektonicznych i projektowania architektur oprogramowania sieciowego wyraźnie wspomina REST i HTTP w 6.3: REST dotyczy HTTP.
20
HTTP nie jest wymagany dla REST.
nategood
1
Książka RESTful Web Services jest dostępna za darmo na stronie: crummy.com/writing/RESTful-Web-Services
icc97
Planowałem przeczytać książkę, a potem zdałem sobie sprawę, że jest przeznaczona głównie dla formatu XML. Czy powinienem skorzystać z tej książki, biorąc pod uwagę popularność JSON? Lub nie zależy to od formatu wymiany danych. Potrzebujesz wskazówek.
Bhargav Jhaveri
72

Możesz także przyjrzeć się OAuth , nowemu , otwartemu protokołowi autoryzacji opartej na tokenach, specjalnie ukierunkowanej na http api.

Jest bardzo podobny do podejścia zastosowanego przez flickr i pamięta mleczny „odpoczynek” apis (niekoniecznie dobre przykłady uspokajających apis, ale dobre przykłady podejścia opartego na tokenie).

John Spurlock
źródło
3
Ale wydaje się, że 2-nogowy oAuth, który moim zdaniem jest tutaj potrzebny, nie jest objęty (brak informacji) tak bardzo, jak 3-nogowy.
redben
4
OAuth dotyczy przekazania uprawnień, tj. Ja, właściciel informacji / konta, pozwalam usłudze A na interakcję z moimi danymi w usłudze B (np. Pozwalam Twitterowi pisać na moim Facebooku). Nie jest to autoryzacja w szerszym znaczeniu, która polega na kontrolowaniu tego, co użytkownicy mogą zrobić z zasobami (dane, informacje, usługi ...). Tutaj wkracza XACML. XACML pozwala zdefiniować zasady autoryzacji dotyczące tego, kto może co robić.
David Brossard,
60

Na Github znajduje się świetna lista kontrolna :

Poświadczenie

  • Nie wymyślaj ponownie koła w uwierzytelnianiu, generowaniu tokenów, przechowywaniu haseł. Skorzystaj ze standardów.

  • Użyj Max Retryi funkcje więzienia w Login.

  • Użyj szyfrowania wszystkich wrażliwych danych.

JWT (token sieciowy JSON)

  • Użyj losowego, skomplikowanego klucza (JWT Secret), aby brutalnie wymusić token bardzo mocno.

  • Nie wyodrębniaj algorytmu z ładunku. Wymuś algorytm w backendzie (HS256 lub RS256).

  • Ustaw termin ważności tokena ( TTL, RTTL) tak krótko, jak to możliwe.

  • Nie przechowuj wrażliwych danych w JWTładunku, można je łatwo odkodować.

OAuth

  • Zawsze sprawdzaj poprawność po redirect_uristronie serwera, aby zezwalać tylko na adresy URL z białej listy.

  • Zawsze staraj się wymieniać na kod, a nie na tokeny (nie zezwalaj response_type=token).

  • Użyj parametru stanu z losową wartość mieszania, aby zapobiec CSRFw OAuthprocesie uwierzytelniania.

  • Zdefiniuj zakres domyślny i sprawdź parametry zakresu dla każdej aplikacji.

Dostęp

  • Ogranicz żądania (ograniczanie), aby uniknąć ataków DDoS / brute-force.

  • Użyj HTTPS po stronie serwera, aby uniknąć MITM (Man In The Middle Attack)

  • Użyj HSTSnagłówka z SSL, aby uniknąć ataku SSL Strip.

Wejście

  • Użyj odpowiedniej metody HTTP zgodnie z operacją: GET(czytaj), POST(twórz), PUT/PATCH(zamień / aktualizuj) i DELETE(aby usunąć rekord) i odpowiedz, 405 Method Not Allowedjeśli żądana metoda nie jest odpowiednia dla żądanego zasobu.

  • Validate Content-Type na żądanie Acceptnagłówku (Negotiation Content), aby umożliwić tylko swój obsługiwanego formatu (np application/xml, application/jsonitp) i odpowiedzieć 406 Not Acceptableodpowiedzi, jeśli nie pasują do siebie.

  • Testuj content-typez wysłane dane, jak zaakceptować (np application/x-www-form-urlencoded, multipart/form-data, application/jsonitp).

  • Sprawdź poprawność danych wprowadzanych przez użytkownika, aby uniknąć typowych luk (np. XSS, SQL-Injection, Remote Code Execution itp.).

  • Nie używaj żadnych poufnych danych (poświadczeń, haseł, tokenów bezpieczeństwa lub kluczy API) w adresie URL, ale użyj standardowego Authorizationnagłówka.

  • Skorzystaj z usługi API Gateway, aby włączyć buforowanie, Rate Limitzasady (np. Limit, aresztowanie skoków, równoczesny limit prędkości) i dynamicznie wdrażać zasoby API.

Przetwarzanie

  • Sprawdź, czy wszystkie punkty końcowe są chronione za uwierzytelnieniem, aby uniknąć przerwanego procesu uwierzytelniania.

  • Należy unikać identyfikatora własnego zasobu użytkownika. Użyj / me / zamówień zamiast / user / 654321 / zamówień.

  • Nie automatycznie zwiększaj identyfikatorów. Zamiast tego użyj UUID.

  • Jeśli parsujesz pliki XML, upewnij się, że parsowanie encji nie jest włączone, aby uniknąć XXE (atak zewnętrznych encji XML).

  • Jeśli analizujesz pliki XML, upewnij się, że ekspansja encji nie jest włączona, aby uniknąć miliardowej śmiechu / bomby XML poprzez wykładniczy atak ekspansji encji.

  • Użyj CDN do przesyłania plików.

  • Jeśli masz do czynienia z ogromną ilością danych, korzystaj z Workers and Queues, aby przetwarzać jak najwięcej w tle i szybko zwracać odpowiedzi, aby uniknąć blokowania HTTP.

  • Nie zapomnij wyłączyć trybu DEBUG .

Wynik

  • Wyślij X-Content-Type-Options: nosniffnagłówek.

  • Wyślij X-Frame-Options: denynagłówek.

  • Wyślij Content-Security-Policy: default-src 'none'nagłówek.

  • Usunąć nagłówki odcisków palców - X-Powered-By, Server, X-AspNet-Versionitd.

  • Wymuś content-typeodpowiedź, jeśli wrócisz, application/jsontyp treści odpowiedzi to application/json.

  • Nie zwracaj poufnych danych, takich jak poświadczenia, hasła, tokeny bezpieczeństwa.

  • Zwróć odpowiedni kod stanu zgodnie z zakończoną operacją. (na przykład 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Alloweditp).

Andrejs
źródło
1
Ładna lista, choć nieco uparta, a zaczyna się od nonsensownego imho: „Nie używaj uwierzytelniania podstawowego Użyj standardowego uwierzytelnienia (np. JWT, OAuth)”. Nie można uzyskać więcej standardowego niż uwierzytelnianie podstawowe i ma swoje miejsce, szczególnie w przypadku interfejsów API, w których klienci nie są przeglądarkami (w przypadku przeglądarek JWT jest zwykle bardziej odpowiedni). Z drugiej strony OAuth używa do uwierzytelniania całego zestawu kompromisów i nie jest tak naprawdę porównywalny z Basic Auth i JWT.
johndodo
Masz rację, BasicAuth z HTTPS jest powszechne, ale jest dyskutowana - security.stackexchange.com/questions/988/... . I tak usunę ten punkt.
Andrejs,
43

Jestem trochę zaskoczony, że SSL nie został jeszcze wspomniany. To prawda, że ​​takie podejście jest naprawdę przydatne tylko wtedy, gdy można liczyć na to, że społeczność użytkowników zostanie zidentyfikowana na podstawie certyfikatów. Jednak wiele rządów / firm wydaje je użytkownikom. Użytkownik nie musi się martwić o utworzenie kolejnej kombinacji nazwy użytkownika / hasła, a tożsamość jest ustalana dla każdego połączenia, dzięki czemu komunikacja z serwerem może być całkowicie bezstanowa, bez konieczności sesji użytkownika. (Nie oznacza to, że którekolwiek / wszystkie inne wymienione rozwiązania wymagają sesji)

śmierdzący
źródło
W rzeczywistości używamy tego do niektórych integracji, a także do szyfrowanych tuneli VPN w celu obsługi starszych systemów, których nie kontrolujemy i które nie mogą komunikować się za pośrednictwem protokołu https.
Casey
Certyfikaty klienta mogą powodować problemy, gdy potrzebujesz równoważenia obciążenia ... można to zrobić, ale jest to mniej proste.
Jeremy Logan
2
@fiXedd - Przeciwnie jest moje doświadczenie z certyfikatami klienta, ponieważ są one naprawdę bezstanowe. Połączenia uwierzytelnione certyfikatem klienta mogą być równoważone obciążeniem za pomocą głupiego modułu równoważenia obciążenia, bez względu na kleistość połączenia, ponieważ wymagają absolutnie zerowego stanu współdzielenia między klientem a serwerem.
stinkymatt,
4
Och, możesz to zrobić ... możesz po prostu ustawić moduł równoważenia obciążenia przekazujący ruch TCP, ale nie możesz na przykład ustawić modułu równoważenia obciążenia jako punktu końcowego protokołu SSL.
Jeremy Logan,
Czy nadal jest bezpieczny, jeśli certyfikaty klienta i jego główne uprawnienia są podpisane przez siebie? Organ główny zostanie zaimportowany do zaufanych głównych ośrodków certyfikacji klienta.
Joyce
38

Wszyscy w tych odpowiedziach przeoczyli prawdziwą kontrolę dostępu / autoryzację.

Jeśli na przykład twoje interfejsy API / usługi REST dotyczą POSTING / GETing dokumentacji medycznej, możesz chcieć zdefiniować politykę kontroli dostępu dotyczącą tego, kto może uzyskać dostęp do danych i w jakich okolicznościach. Na przykład:

  • lekarze mogą uzyskać dokumentację medyczną pacjenta, z którym są związani opieką
  • nikt nie może wysłać danych medycznych POST poza godzinami ćwiczeń (np. od 9 do 5)
  • użytkownicy końcowi mogą uzyskać posiadaną przez siebie dokumentację medyczną lub dokumentację medyczną pacjentów, których są opiekunami
  • pielęgniarki mogą AKTUALIZOWAĆ dokumentację medyczną pacjenta należącego do tej samej jednostki, co pielęgniarka.

Aby zdefiniować i wdrożyć te drobiazgowe autoryzacje, musisz użyć opartego na atrybutach języka kontroli dostępu o nazwie XACML, eXtensible Access Control Markup Language.

Pozostałe standardy dotyczą:

  • OAuth: id. federacja i delegacja autoryzacji, np. zezwolenie usłudze na działanie w moim imieniu w innym serwisie (Facebook może publikować na moim Twitterze)
  • SAML: federacja tożsamości / internetowe logowanie jednokrotne. SAML bardzo zależy od tego, kim jest użytkownik.
  • Standardy WS-Security / WS- *: koncentrują się na komunikacji między usługami SOAP. Są one specyficzne dla formatu komunikatów na poziomie aplikacji (SOAP) i zajmują się takimi aspektami przesyłania wiadomości, jak niezawodność, bezpieczeństwo, poufność, integralność, atomowość, zdarzanie ... Żadne nie obejmują kontroli dostępu i wszystkie są specyficzne dla SOAP.

XACML jest niezależny od technologii. Może być stosowany do aplikacji Java, .NET, Python, Ruby ... usług internetowych, interfejsów API REST i innych.

Oto interesujące zasoby:

David Brossard
źródło
2
Nie rozumiem, dlaczego nie możesz po prostu wdrożyć systemu tokenów, który uzyska użytkownika i jego uprawnienia, które zasadniczo będą tym samym?
Stan
Możesz zastosować podejście oparte na tokenie. To również działa dobrze, ale nadal potrzebujesz logiki, która określa, jakie uprawnienia użytkownicy uzyskują, innymi słowy, jakie uprawnienia do wstawiania wewnątrz tokena. To właśnie pomaga XACML. Pozwala to również uniknąć wzdęcia tokena.
David Brossard
2
Na marginesie, co „9 do 5” przyczynia się do bezpieczeństwa? Jakby napastnicy byli aktywni tylko w nocy? Nie mówiąc już o poważnych konsekwencjach używania, tak jakby lekarze pracowali tylko „od 9 do 5”.
Roland,
Jest to powszechny wymóg w scenariuszach opieki zdrowotnej. Sprawdź na przykład HL7. Istnieją również scenariusze zbicia szyby na wypadek, gdyby lekarz potrzebował dostępu poza godzinami pracy. Jeśli chodzi o hakerów, kiedy już wszyscy wezmą udział, zakłady są wyłączone
David Brossard,
1
Niektórzy z moich kolegów rzeczywiście to badają. Dzięki @SimplyG.
David Brossard,
25

Używałem OAuth kilka razy, a także innych metod (BASIC / DIGEST). Z całego serca sugeruję OAuth. Poniższy link to najlepszy samouczek, jaki widziałem przy użyciu OAuth:

http://hueniverse.com/oauth/guide/

Rob Ottaway
źródło
Chociaż jest to bardzo stara odpowiedź odnosząca się do OAuth 1.0, warto zauważyć, że autor cytowanego linku miał to do powiedzenia na temat OAuth 2.0 : „Doszedłem do wniosku, że OAuth 2.0 to zły protokół ... W porównaniu z OAuth 1.0, specyfikacja 2.0 jest bardziej złożona, mniej interoperacyjna, mniej użyteczna, bardziej niekompletna, a co najważniejsze, mniej bezpieczna ”. . Dla jasności cytowany przeze mnie komentarz został opublikowany kilka lat po opublikowaniu odpowiedzi.
skomisa
17

Jeden z najlepszych postów, jakie kiedykolwiek spotkałem, dotyczący bezpieczeństwa w związku z REST, został zakończony o 1 RainDrop . Interfejs API MySpace korzysta z OAuth również dla bezpieczeństwa, a ty masz pełny dostęp do ich niestandardowych kanałów w kodzie RestChess, z którym dużo eksplorowałem. Zostało to pokazane w Mix i post można znaleźć tutaj .

degnome
źródło
Dzięki za link (1 RainDrop) - bardzo interesująca dyskusja na temat bezpieczeństwa w odniesieniu do SOAP v REST
Nathan
15

Dzięki za doskonałą poradę. Ostatecznie użyliśmy niestandardowego nagłówka HTTP, aby przekazać token tożsamości od klienta do usługi, przygotowując się do integracji naszego interfejsu API RESTful z nadchodzącą platformą Zermatt Identity firmy Microsoft. Opisałem tutaj problem i nasze rozwiązanie tutaj . Skorzystałem również z porady tweakt i kupiłem RESTful Web Services - bardzo dobrą książkę, jeśli budujesz API RESTful jakiegokolwiek rodzaju.

Nathan
źródło
1
To podejście wydaje mi się podejrzane. Co uniemożliwia atakującemu użycie tokenu tożsamości do maskarady klienta? HTTPS nie chroni adresu URL ani nagłówków podczas ostatniego sprawdzania ...
Gili,
2
Hmmm ... nie jestem pewien, czy masz rację. Uważam, że oprócz kilku nagłówków wymaganych do zrozumienia, jaki rodzaj szyfrowania jest wymagany, wszystkie inne nagłówki są szyfrowane.
Nathan
51
To jest złe. HTTPS chroni WSZYSTKO. To znaczy: Uścisk dłoni TCP ... Uścisk dłoni TLS ... <ENCRYPTED> GET / foo 200 OK ... porzucenie </ENCRYPTED>.
Mark Renouf
1
Pamiętaj, że możesz również przekazać token jako plik cookie (zamiast niestandardowego nagłówka). Zachowuje się to dobrze w przeglądarkach, ponieważ wykorzystuje nagłówek HTTP ze standardowymi zachowaniami w większości zestawów narzędzi i aplikacji. Po stronie usługi plik cookie nie musi odnosić się do sesji, można go użyć do komunikacji z dowolnym tokenem.
Bruce Alderson
11
Wayback Machine to piękna rzecz: opis problemu i rozwiązanie
cjc343,
14

OWASP (Open Web Application Security Project) zawiera niektóre ściągawki dotyczące wszystkich aspektów rozwoju aplikacji internetowych. Ten projekt jest bardzo cennym i wiarygodnym źródłem informacji. Jeśli chodzi o usługi REST, możesz to sprawdzić: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

WelsonJR
źródło
7

Polecam OAuth 2/3. Więcej informacji można znaleźć na stronie http://oauth.net/2/

Abhijit Gaikwad
źródło
8
Zastanów się, dlaczego poleciłbyś wersję 2, jeśli jest ona w dużej mierze niekompletna? IMHO, wersja 1.0a pozostaje solidnym rozwiązaniem dla większości aplikacji.
Butifarra,
6

Dużo szukałem o bezpieczeństwie WS, a także do uwierzytelnienia żądań wykorzystaliśmy token za pośrednictwem plików cookie od klienta do serwera. Użyłem zabezpieczenia wiosennego do autoryzacji żądań w służbie, ponieważ musiałem uwierzytelniać i autoryzować każde żądanie w oparciu o określone zasady bezpieczeństwa, które już były w DB.

Parisa Kachoui
źródło
6

Fakt, że świat SOAP jest dość dobrze objęty standardami bezpieczeństwa, nie oznacza, że ​​jest domyślnie bezpieczny. Po pierwsze, standardy są bardzo złożone. Złożoność nie jest dobrym przyjacielem dla luk w zabezpieczeniach i implementacji, takich jak ataki polegające na owijaniu podpisów XML, są tu powszechne.

Jeśli chodzi o środowisko .NET I nie pomogą wiele, ale „budowanie serwisów internetowych z Java” (cegły z ~ 10 autorów) pomogło mi wiele zrozumienia WS- * architektury bezpieczeństwa, a przede wszystkim, jego dziwactwa.

kravietz
źródło
4

Sam REST nie oferuje żadnych standardów bezpieczeństwa, ale takie rzeczy jak OAuth i SAML szybko stają się standardami w tej przestrzeni. Jednak uwierzytelnianie i autoryzacja 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 Morschel
źródło
4

Chcę dodać (zgodnie ze stinkeymatt), najprostszym rozwiązaniem byłoby dodanie certyfikatów SSL do Twojej witryny. Innymi słowy, upewnij się, że twój adres URL to HTTPS: //. To zapewni bezpieczeństwo transportu (huk za złotówkę). W przypadku adresu URL RESTful pomysł jest prosty (w przeciwieństwie do WS * security / SAML), możesz użyć oAuth2 / openID connect lub nawet Basic Auth (w prostych przypadkach). Ale nadal będziesz potrzebować SSL / HTTPS. Sprawdź zabezpieczenia ASP.NET Web API 2 tutaj: http://www.asp.net/web-api/overview/security (artykuły i filmy)

Manish Jain
źródło
3

Ponieważ @Nathan skończył z prostym nagłówkiem HTTP, a niektórzy powiedzieli OAuth2 i certyfikaty SSL po stronie klienta. W istocie chodzi o to, że ... interfejs API REST nie powinien obsługiwać zabezpieczeń, ponieważ tak naprawdę nie powinien on być objęty zakresem interfejsu API.

Zamiast tego należy nałożyć na nią warstwę bezpieczeństwa, niezależnie od tego, czy jest to nagłówek HTTP za web proxy (powszechne podejście, takie jak SiteMinder, Zermatt, a nawet Apache HTTPd), czy tak skomplikowane jak OAuth 2.

Kluczową sprawą jest to, że żądania powinny działać bez interakcji użytkownika końcowego. Wystarczy upewnić się, że połączenie z interfejsem API REST jest uwierzytelnione. W Java EE mamy pojęcie, userPrincipalże można uzyskać na HttpServletRequest. W deskryptorze wdrażania zarządza się również, że wzorzec adresu URL może być bezpieczny, więc kod API REST nie musi już sprawdzać.

W świecie WCF chciałbym użyć, ServiceSecurityContext.Currentaby uzyskać bieżący kontekst bezpieczeństwa. Musisz skonfigurować aplikację tak, aby wymagała uwierzytelnienia.

Jest jeden wyjątek od oświadczenia, które miałem powyżej i jest to użycie nonce, aby zapobiec powtórkom (mogą to być ataki lub ktoś po prostu przesyłający te same dane dwa razy). Ta część może być obsługiwana tylko w warstwie aplikacji.

Archimedes Trajano
źródło
3

Jeśli chodzi o bezpieczeństwo aplikacji sieci Web, powinieneś zapoznać się z OWASP ( https://www.owasp.org/index.php/Main_Page ), który zawiera kody do różnych ataków bezpieczeństwa. Możesz zastosować jak najwięcej środków, aby zabezpieczyć swoją aplikację. W odniesieniu do bezpieczeństwa API (autoryzacja, uwierzytelnianie, zarządzanie tożsamością) istnieje wiele sposobów, jak już wspomniano (Basic, Digest i OAuth). W OAuth1.0 są dziury w pętli, więc możesz używać OAuth1.0a (OAuth2.0 nie jest powszechnie stosowany ze względu na problemy ze specyfikacją)

java_geek
źródło
2

Minęło trochę czasu, ale pytanie jest nadal aktualne, choć odpowiedź mogła się nieco zmienić.

Interfejs API Gateway byłby elastycznym i wysoce konfigurowalnym rozwiązaniem. Testowałem i używałem KONG całkiem sporo i bardzo podobało mi się to, co widziałem. KONG zapewnia własny interfejs API REST administratora, którego można używać do zarządzania użytkownikami.

Express-gateway.io jest nowszy i jest również bramą API.

Matt Bannert
źródło