Najlepsze praktyki zabezpieczania REST API / usługi internetowej [zamknięte]

Nie ma innych standardów dla REST niż HTTP. Istnieją ustalone usługi odpoczynku tam. Sugeruję, abyś zerknął na nie i poczuł, jak działają.

Na przykład, zapożyczyliśmy wiele pomysłów z usługi Amazon S3 REST podczas opracowywania naszych własnych. Zdecydowaliśmy się jednak nie używać bardziej zaawansowanego modelu zabezpieczeń opartego na podpisach żądań. Prostszym podejściem jest HTTP Basic auth over SSL. Musisz zdecydować, co działa najlepiej w twojej sytuacji.

Również bardzo polecam książkę RESTful Web Services od O ' Reilly. Wyjaśnia podstawowe pojęcia i dostarcza najlepszych praktyk. Ogólnie można wziąć dostarczony model i mapować go do własnej aplikacji.

Możesz również przyjrzeć się OAuth, powstającemu otwartemu protokołowi autoryzacji opartej na tokenach, specjalnie ukierunkowanemu na interfejsy API http.

Jest to bardzo podobne do podejścia zastosowanego przez flickr i remember The milk "rest" API (niekoniecznie dobre przykłady restful API, ale dobre przykłady podejścia opartego na tokenach).

Jestem trochę zaskoczony, że SSL z certyfikatami klienta nie został jeszcze wymieniony. Oczywiście, takie podejście jest naprawdę przydatne tylko wtedy, gdy można liczyć na społeczność użytkowników zidentyfikowanych przez certyfikaty. Ale wiele rządów / firm wydaje je swoim użytkownikom. Użytkownik nie musi się martwić o utworzenie kolejnej kombinacji nazwy użytkownika/hasła, a tożsamość jest ustalana przy każdym połączeniu, więc komunikacja z serwerem może być całkowicie bezpaństwowa, bez użytkownika wymagane sesje. (Nie sugerując, że jakiekolwiek / wszystkie inne wymienione rozwiązania wymagają sesji)

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

Jeśli na przykład Twoje REST API / usługi internetowe dotyczą publikowania / uzyskiwania dokumentacji medycznej, możesz zdefiniować kontrolę dostępu policie o tym, 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 mają związek opiekuńczy
• nikt nie może zamieszczać danych medycznych poza godzinami pracy (np. 9 do 5)
Użytkownicy końcowi mogą uzyskać własną dokumentację medyczną lub dokumentację medyczną pacjentów, dla których są opiekunem Pielęgniarki mogą aktualizować dokumentację medyczną pacjenta, który należy do tej samej jednostki co Pielęgniarka.

Aby zdefiniować i zaimplementować te drobnoziarniste uprawnienia, musisz użyć języka kontroli dostępu opartego na atrybutach o nazwie XACML, rozszerzalny język znaczników kontroli dostępu.

Inne standardy tutaj są dla po:

• OAuth: id. Federacja i delegacja autoryzacji, np. pozwolenie na działanie usługi w moim imieniu w innej usłudze (Facebook może publikować na moim Twitterze)
• SAML: identity federation / web SSO. SAML jest bardzo dużo o tym, kim jest użytkownik.
[[5]}standardy WS-Security / ws -*: koncentrują się one na komunikacji między usługami SOAP. Są one specyficzne dla formatu wiadomości na poziomie aplikacji (SOAP) i zajmują się aspektami wiadomości, np. niezawodność, bezpieczeństwo, poufność, uczciwość, atomiczność, WKKW... Żaden nie obejmuje kontroli dostępu i wszystkie są specyficzne dla SOAP.

XACML jest technologiczny. Może być stosowany do aplikacji java,. NET, Python, Ruby... Usługi internetowe, interfejsy API REST i inne.

Oto interesujące zasoby:

• strona internetowa OASIS XACML
• norma NIST ABAC

[[37]}istnieje wielka lista kontrolna znaleziona na Github :

Uwierzytelnianie

• Nie odkrywaj koła na nowo w uwierzytelnianiu, generowaniu tokenów, przechowywaniu haseł. Użyj standardów.

• Użyj Max Retry i funkcji jail w Login.

• Użyj szyfrowania wszystkich poufnych danych.

JWT (JSON Web Token)

• Użyj losowego skomplikowanego klucza (JWT Secret), aby zrobić brute wymuszanie żetonu bardzo mocno.

• Nie wyciągaj algorytmu z ładunku. Wymuś algorytm w backendzie (HS256 lub RS256).

• Spraw, aby wygasł token(TTL, RTTL) tak krótko, jak to możliwe.

• Nie przechowuj poufnych danych w ładunku JWT, można je łatwo dekodować.

OAuth

• Zawsze sprawdzaj poprawność redirect_uri Po stronie serwera, aby zezwolić tylko na białą listę Url.

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

• Użyj parametru state z losowym skrótem, aby zapobiec CSRF w procesie uwierzytelniania OAuth.

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

Dostęp

• Ograniczaj żądania (Dławienie), aby uniknąć ataków DDoS / brute-force.

• Użyj HTTPS na serwerze strona, aby uniknąć MITM (Man in the Middle Attack)

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

Input

• Użyj odpowiedniej metody HTTP zgodnie z operacją: GET (read), POST (create), PUT/PATCH (replace/update) i DELETE (aby usunąć rekord), i odpowiedz 405 Method Not Allowed jeśli żądana metoda nie jest odpowiednia dla żądanego zasobu.

• Weryfikacja typu treści na żądanie Accept nagłówek (negocjacja zawartości), aby umożliwić tylko Obsługiwany format (np. application/xml, application/json, etc) i odpowiedzieć 406 Not Acceptable response jeśli nie jest dopasowana.

• Walidacja content-type opublikowanych danych zgodnie z akceptacją (np. application/x-www-form-urlencoded, multipart/form-data, application/json, itp.).

• Zweryfikuj dane wejściowe użytkownika, aby uniknąć typowych luk (np. XSS, SQL-Injection, zdalne wykonywanie kodu itp.).

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

• Usługa bramy API umożliwia buforowanie, Zasady Rate Limit (np. Quota, Spike Arrest, Concurrent Rate Limit) i dynamiczne wdrażanie zasobów API.

Przetwarzanie

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

• Należy unikać identyfikowania zasobów własnych użytkownika. Użyj/me / orders zamiast / user/654321 / orders /

• Nie dodawaj identyfikatorów auto-increment. Zamiast tego użyj UUID.

• Jeśli analizujesz pliki XML, upewnij się, że przetwarzanie encji nie jest włączone, aby uniknąć XXE (XML external entity attack).

• Jeśli analizujesz pliki XML, upewnij się, że rozszerzenie encji nie jest włączone, aby uniknąć bomby Billion Laughs/XML poprzez exponential entity expansion attack.

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

• Jeśli masz do czynienia z ogromna ilość danych, korzystaj z pracowników i kolejek, aby przetwarzać jak najwięcej w tle i szybko zwracać odpowiedzi, aby uniknąć blokowania HTTP.

• Nie zapomnij wyłączyć trybu debugowania .

Wyjście

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

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

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

• Usuń nagłówki odcisków palców - X-Powered-By, Server, X-AspNet-Version itd.

• Wymuś content-type dla swojej odpowiedzi, jeśli zwrócisz {[16] } wtedy Twoja treść odpowiedzi to application/json.

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

• Zwraca właściwy kod statusu zgodnie z zakończoną operacją. (np. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, itp.).

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

Http://hueniverse.com/oauth/guide/

Jeden z najlepszych postów, na jakie kiedykolwiek natknąłem się w kwestii bezpieczeństwa, ponieważ odnosi się do odpoczynku, kończy się na 1 kropla deszczu . API MySpace używa OAuth również dla bezpieczeństwa i masz pełny dostęp do ich niestandardowych kanałów w kodzie RestChess, z którym zrobiłem wiele eksploracji. To było demo na Mix i możesz znaleźć Post tutaj.

Dzięki za wspaniałą radę. Skończyło się na użyciu niestandardowego nagłówka HTTP, aby przekazać token tożsamości od klienta do usługi, w ramach przygotowań do integracji naszego RESTful API z nadchodzącym Zermatt Identity framework od Microsoft. Opisałem problem tutaj 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 jakiekolwiek API RESTful.

OWASP (Open Web Application Security Project) zawiera kilka arkuszy oszukiwania dotyczących wszystkich aspektów tworzenia aplikacji internetowych. Ten projekt jest bardzo cennym i wiarygodnym źródłem informacji. Jeśli chodzi o usługi wypoczynkowe, 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/

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 zbyt dobrym przyjacielem bezpieczeństwa i luk implementacyjnych, takich jak ataki XML signature wrapping są tutaj endemiczne.

Jeśli chodzi o środowisko. NET to niewiele pomogę, ale "budowanie serwisów WWW za pomocą Javy" (klocek z ~10 autorami) mi pomógł a lot w zrozumieniu architektury bezpieczeństwa WS -*, a zwłaszcza jej dziwactw.

Szukałem wiele o restful WS security i skończyło się również na użyciu tokena przez cookie z Klienta na serwer do uwierzytelniania żądań . Użyłem spring security do autoryzacji żądań w serwisie, ponieważ musiałem uwierzytelnić i autoryzować każde żądanie w oparciu o określone zasady bezpieczeństwa, które już były w DB.

REST sam w sobie nie oferuje standardów bezpieczeństwa, ale rzeczy takie 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 dotyczy w dużym stopniu interfejsów API REST. Musisz wziąć pod uwagę walidację danych wejściowych, pękanie sesji, niewłaściwe 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 adres url jest HTTPS://. To pokryje twoje bezpieczeństwo transportu (bang for the buck). W przypadku RESTful url ' s, idea jest taka, aby było to proste (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. Proszę sprawdzić ASP.NET bezpieczeństwo Web API 2 tutaj: http://www.asp.net/web-api/overview/security (Artykuły i filmy)

Jako @ Nathan skończył z którym jest prosty nagłówek HTTP, a niektórzy mówili OAuth2 i certyfikaty SSL po stronie klienta. Sedno sprawy jest takie... Twoje API REST nie powinno obsługiwać zabezpieczeń, ponieważ powinno to naprawdę wykraczać poza zakres API.

Zamiast tego należy umieścić na niej warstwę bezpieczeństwa, niezależnie od tego, czy jest to nagłówek HTTP za serwerem proxy (wspólne podejście, takie jak SiteMinder, Zermatt lub nawet Apache HTTPd), czy tak skomplikowane, jak OAuth 2.

Kluczową rzeczą jest wnioski powinny działać bez interakcji użytkownika końcowego. Wszystko, co jest potrzebne, to upewnić się, że połączenie z REST API jest uwierzytelnione. W Javie EE mamy pojęcie userPrincipal, które można uzyskać na HttpServletRequest. W deskryptorze wdrażania zarządzane jest również to, że wzorzec URL może być bezpieczny, więc kod REST API nie musi już sprawdzać.

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

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

Aby zabezpieczyć Aplikacje Internetowe, należy spojrzeć na OWASP ( https://www.owasp.org/index.php/Main_Page ), który udostępnia arkusze cheatsheets dla 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). Istnieją otwory pętli w OAuth1. 0, więc można użyć OAuth1. 0a (OAuth2. 0 nie jest szeroko przyjęte ze względu na obawy związane ze specyfikacją)

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

Brama API byłaby elastycznym i wysoce konfigurowalnym rozwiązaniem. Przetestowałem i użyłem KONG dość dużo i bardzo podobało mi się to, co zobaczyłem. KONG zapewnia własne API REST administratora, którego możesz używać do zarządzania użytkownikami.

Express-gateway.io jest nowsza i jest również bramką API.