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

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.

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.

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ę.

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).

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).

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)

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:

• strona internetowa OASIS XACML
• standardem NIST ABAC

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/

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 .

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.

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

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

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.

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.

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.

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)

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.

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ą)

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.