OWASP – 10 najczęstszych zagrożeń

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

W tym dokumencie opisujemy różne podejścia, które możesz zastosować w Apigee, aby rozwiązać problemy z lukami w zabezpieczeniach zidentyfikowanymi przez OWASP. Dodatkowe podejścia opisane w dokumentacji Apigee znajdziesz w artykule Możliwości łagodzenia zagrożeń z listy OWASP Top 10 2021 w Google Cloud.

Przegląd

Ekosystemy interfejsów API są narażone na różne ataki ze strony klientów zewnętrznych i wewnętrznych. Oferowanie i używanie interfejsów API stwarza ogromne możliwości dla dostawców usług, ale wiąże się też z pewnymi zagrożeniami dla bezpieczeństwa. Deweloperzy muszą być świadomi tych wyzwań i uwzględniać je podczas tworzenia i używania interfejsów API.

OWASP to otwarta społeczność, która pomaga organizacjom tworzyć, kupować i utrzymywać zaufane aplikacje i interfejsy API. W ramach projektu OWASP API Security organizacja OWASP publikuje informacje o najbardziej krytycznych zagrożeniach dla bezpieczeństwa aplikacji internetowych i interfejsów API REST oraz zalecenia dotyczące radzenia sobie z tymi zagrożeniami.

Dzięki Apigee warstwa proxy interfejsu API może wykrywać, blokować i zgłaszać nieprawidłowo sformułowane żądania interfejsu API od klienta zanim zostaną one przetworzone w systemach backendu. Pozwala to zmniejszyć ryzyko i chronić usługi. Nieprawidłowo sformułowane żądania mogą zawierać dowolny komponent, który tworzy protokół HTTP na poziomie aplikacji:

  • URL
  • Nagłówki
  • Ścieżka
  • Ładunek

Nieprawidłowo sformułowane żądania interfejsu API mogą pochodzić od znanych lub nieznanych klientów opracowanych przez deweloperów zewnętrznych, deweloperów wewnętrznych lub złośliwe boty. Te typy żądań stanowią większość zagrożeń OWASP, ale istnieją dodatkowe komponenty bazowej warstwy proxy interfejsu API, które mogą zmniejszać ryzyko, takie jak maskowanie danych, logowanie, administracja itp.

Inteligentna platforma do zarządzania interfejsami API Apigee umożliwia bezproblemowe radzenie sobie z najważniejszymi lukami w zabezpieczeniach interfejsów API OWASP gdy stosujesz podejście do projektowania interfejsów API oparte na konsumpcji i łączysz je z systemami backendu. Poniżej znajdziesz listę zasad i konfiguracji , które Apigee zaleca w przypadku najważniejszych zagrożeń OWASP związanych z interfejsami REST.

Rozwiązania Apigee dotyczące listy OWASP Top 10 2017

Podczas tworzenia i zabezpieczania aplikacji internetowych należy wziąć pod uwagę wiele kwestii związanych z bezpieczeństwem. OWASP opublikowała listę 10 najważniejszych zagrożeń dla bezpieczeństwa aplikacji internetowych w 2017 r.. Aplikacja internetowa składa się z wielu części, ale większość nowoczesnych aplikacji internetowych w dużym stopniu opiera się na interfejsach API REST. Apigee nie jest przeznaczona do obsługi wszystkich potrzeb związanych z bezpieczeństwem aplikacji internetowej, ale może odgrywać kluczową rolę w zabezpieczaniu interfejsów API REST. Poniżej znajdziesz najważniejsze zagrożenia dla bezpieczeństwa OWASP wraz z opisem, jak możesz użyć Apigee aby sobie z nimi poradzić.

A1:2017 – wstrzyknięcie

Aby chronić się przed wstrzykiwaniem niezaufanych danych, takich jak SQL, NoSQL, LDAP i JavaScript, które mogą prowadzić do wykonywania niepożądanych poleceń lub nieautoryzowanego dostępu do danych, Apigee udostępnia kilka zasad weryfikacji danych wejściowych . Dzięki nim możesz sprawdzić, czy wartości podane przez klienta są zgodne z oczekiwaniami, zanim zezwolisz na dalsze przetwarzanie. Apigee Edge, działając jako serwer dla przychodzących żądań interfejsu API, sprawdza, czy struktura ładunku mieści się w dopuszczalnym zakresie, co jest znane jako sprawdzanie limitu. Możesz skonfigurować proxy interfejsu API tak, aby procedura weryfikacji danych wejściowych przekształcała dane wejściowe w celu usunięcia ryzykownych sekwencji znaków i zastąpienia ich bezpiecznymi wartościami.

Istnieje kilka sposobów weryfikowania danych wejściowych za pomocą platformy Apigee:

Sprawdzanie typów treści:

A2:2017 – nieprawidłowe uwierzytelnianie i zarządzanie sesjami

Osoby atakujące mogą uzyskiwać dostęp do haseł, tokenów sesji i kluczy, aby podszywać się pod innych użytkowników, wykorzystując luki w implementacji aplikacji. Jest to raczej problem z implementacją niż problem z produktem. Apigee udostępnia zasady VerifyApiKey, OAuth i JSON Web Token (JWT), które pomagają chronić się przed tą luką w zabezpieczeniach.

Weryfikacja klucza interfejsu API

Weryfikacja klucza interfejsu API to najprostsza forma zabezpieczeń opartych na aplikacji, którą można skonfigurować dla interfejsu API. Aplikacja kliencka po prostu przedstawia klucz interfejsu API w swoim żądaniu, a Apigee Edge za pomocą zasady dołączonej do proxy interfejsu API sprawdza, czy klucz interfejsu API jest w zatwierdzonym stanie dla żądanego zasobu.

Apigee obsługuje generowanie i weryfikowanie kluczy interfejsu API. Apigee generuje klucz interfejsu API i klucz tajny, gdy tworzona jest i zatwierdzana aplikacja dewelopera połączona z co najmniej 1 usługą API.

Termin „klucze interfejsu API” może czasami oznaczać różne rzeczy. W Apigee, gdy tworzona jest relacja między aplikacją a usługą, Apigee generuje identyfikator klienta i klucz tajny klienta. Niektórzy nazywają zarówno identyfikator, jak i klucz tajny kluczem interfejsu API. Niektórzy nazywają kluczem interfejsu API tylko identyfikator klienta. W interfejsie Edge zobaczysz „klucz klienta” i „klucz tajny klienta”.

W zasadzie VerifyAPIKey weryfikowany jest tylko identyfikator klienta, czyli "klucz klienta" . Deweloperzy otrzymują klucz klienta, gdy zarejestrują swoją aplikację w Apigee i powiążą ją z usługą API. Deweloperzy umieszczają klucz klienta w wywołaniach, które aplikacja wykonuje do proxy interfejsów API zawartych w usłudze API.

Apigee obsługuje też importowanie istniejących kluczy interfejsu API ze źródeł zewnętrznych.

W przypadku typów uwierzytelnienia przez OAuth używane są zarówno identyfikator klienta, jak i klucz tajny.

OAuth 2.0

Platforma autoryzacji OAuth 2.0 umożliwia aplikacji innej firmy uzyskanie ograniczonego dostępu do usługi HTTP w imieniu właściciela zasobu przez koordynowanie interakcji zatwierdzania między właścicielem zasobu a usługą HTTP lub przez umożliwienie aplikacji innej firmy uzyskania dostępu we własnym imieniu.

Zasady OAuth 2.0 Apigee umożliwiają implementowanie i dostosowywanie 4 typów uwierzytelniania OAuth 2.0. Egzekwowanie tokena dostępu OAuth można przeprowadzić za pomocą zasady OAuthv2. Klient musi być zarejestrowany i mieć zatwierdzoną aplikację, która przyznaje mu dostęp do interfejsu API. W zamian, otrzyma identyfikator klienta interfejsu API i klucz tajny klienta. Aby się uwierzytelnić, klient musi przejść przez jeden z typów uwierzytelniania OAuth, który przyznaje mu nieprzezroczysty token dostępu. Ten token może służyć do kontrolowania dostępu do interfejsu API.

JWT

Tokeny sieciowe JSON (JWT) są powszechnie używane do udostępniania deklaracji lub asercji między połączonymi aplikacjami. Apigee obsługuje tokeny JWT za pomocą 3 zasad.

  • GenerateJWT tokens (obsługuje podpisy HS256 i RS256)
  • ValidateJWT tokens
  • DecodeJWT tokens without validating

A3:2017 – ujawnienie danych wrażliwych

Osoby atakujące kierują swoje działania na dane wrażliwe, takie jak dane karty kredytowej, numery ubezpieczenia społecznego, dane logowania, informacje umożliwiające identyfikację (PII) i numery podatkowe, aby dopuścić się kradzieży tożsamości, kradzieży pieniędzy, oszustw i innych przestępstw. Aplikacje internetowe muszą implementować szyfrowanie zarówno w stanie spoczynku, jak i w trakcie przesyłania, oraz inne strategie, aby zapewnić ochronę danych wrażliwych.

TLS (Transport Layer Security, którego poprzednikiem jest protokół SSL) to standardowa technologia zabezpieczeń służąca do tworzenia zaszyfrowanego połączenia między serwerem WWW a klientem internetowym, takim jak przeglądarka lub aplikacja. Apigee obsługuje zarówno jednokierunkowy, jak i dwukierunkowy protokół TLS.

Północny TLS (klient łączący się z interfejsem API działającym jako serwer) jest obsługiwany za pomocą konfiguracji hosta wirtualnego. Host wirtualny można skonfigurować na potrzeby jednokierunkowego lub dwukierunkowego protokołu TLS.

Południowy TLS (Apigee jako klient łączący się z usługą backendu) jest obsługiwany za pomocą konfiguracji serwera docelowego. Serwer docelowy można skonfigurować na potrzeby jednokierunkowego lub dwukierunkowego protokołu TLS.

Apigee obsługuje wiele opcji konfiguracji TLS .

Egzekwowanie dwukierunkowego protokołu TLS zapewnia, że klient używa certyfikatu, który został już wdrożony w Apigee. OWASP udostępnia też sprawdzone metody dotyczące protokołu TLS.

W Apigee Hybrid protokół TLS jest dostępny w punkcie wejścia za pomocą aliasu hosta, który jest podobny do hosta wirtualnego.

Poniżej znajdziesz wskazówki dotyczące zabezpieczania danych wrażliwych:

  • Używaj platformy, która obsługuje jednokierunkowy i dwukierunkowy protokół TLS, co zapewni ochronę na poziomie protokołu.
  • Używaj zasad, takich jak AssignMessage i JavaScript, aby usuwać dane wrażliwe, zanim zostaną zwrócone klientowi.
  • Używaj standardowych technik OAuth i rozważ dodanie technik HMAC, hash, state, nonce, PKCE, lub innych, aby zwiększyć poziom uwierzytelniania każdego żądania.
  • Używaj ustawień maskowania danych, aby maskować dane wrażliwe w narzędziu Edge Trace.
  • Uważaj na przechowywanie danych wrażliwych w pamięci podręcznej (lub szyfruj dane wrażliwe przechowywane w pamięci podręcznej). W Edge możesz szyfrować dane wrażliwe w stanie spoczynku w mapach klucz-wartość.

A4:2017 – zewnętrzne encje XML

Systemy lub aplikacje, które przetwarzają XML, muszą obsługiwać "zewnętrzne odwołania do encji" w XML – odwołania do plików lub danych, które są zastępowane rzeczywistymi danymi podczas przetwarzania XML. Jeśli aplikacje lub procesory XML są stare lub źle zaimplementowane, osoby atakujące mogą włamać się do danych i wykorzystać je do kradzieży informacji lub przeprowadzania różnych rodzajów ataków na system, takich jak atak typu DoS.

Zasada ExtractVariables Apigee umożliwia wyodrębnianie treści z żądania lub odpowiedzi i przypisywanie jej do zmiennej. Możesz wyodrębnić dowolną część wiadomości, w tym nagłówki, ścieżki URI, ładunki JSON/XML, parametry formularza i parametry zapytania. Zasada działa przez zastosowanie wzorca tekstowego do treści wiadomości i, po znalezieniu dopasowania, ustawienie zmiennej z określoną treścią wiadomości.

Apigee ma wbudowany parser XML, który jest częścią platformy i używa XPath do wyodrębniania danych. Ma też zasadę XMLThreatProtection, która chroni przed złośliwymi ładunkami XML.

A5:2017 – nieprawidłowa kontrola dostępu

Gdy użytkownicy zalogują się i uzyskają dostęp do systemu, należy wprowadzić odpowiednie mechanizmy kontroli autoryzacji aby użytkownicy mogli zobaczyć i zrobić tylko to, na co mają pozwolenie. Bez silnych mechanizmów kontroli dostępu, osoby atakujące mogą wyświetlać nieautoryzowane i często wrażliwe dane lub złośliwie manipulować danymi i zachowaniem systemu.

Apigee obsługuje warstwowe podejście do implementowania mechanizmów kontroli dostępu, aby uniemożliwić osobom atakującym wprowadzanie nieautoryzowanych zmian lub uzyskiwanie dostępu do systemu.

Mechanizmy kontroli dostępu do interfejsu Edge

Mechanizmy kontroli dostępu do portalu dla deweloperów Apigee

Mechanizmy kontroli dostępu do interfejsu API środowiska wykonawczego Apigee

  • Dostęp do interfejsów API można egzekwować za pomocą kluczy interfejsu API, tokenów OAuth, zakresów OAuth, certyfikatów, i innych technik.
  • Dostawca interfejsu API konfiguruje, które zasoby są dostępne, definiując usługę API. Dostęp jest przyznawany ręcznie w interfejsie, za pomocą interfejsu Management API lub przez portal dla programistów. Gdy aplikacja dewelopera uzyska dostęp do usługi API, deweloper otrzymuje identyfikator klienta i klucz tajny, które są używane w procesie uwierzytelniania.
  • Apigee może integrować się z dowolnym dostawcą tożsamości w celu przeprowadzania uwierzytelniania OAuth.
  • Apigee może generować tokeny JWT lub stosować inne techniki, aby wysyłać tożsamość użytkownika do usług docelowych. Usługi docelowe mogą używać tej tożsamości do ograniczania dostępu do usług i danych w razie potrzeby.

A6:2017 – nieprawidłowa konfiguracja zabezpieczeń

Nieprawidłowe konfiguracje zabezpieczeń łatwo przeoczyć, często dlatego, że administratorzy i deweloperzy błędnie ufają, że używane przez nich systemy są z natury bezpieczne. Nieprawidłowa konfiguracja zabezpieczeń może wystąpić na wiele sposobów, np. przez zaufanie do konfiguracji domyślnych lub częściowe konfiguracje, które mogą być niezabezpieczone, przez pozostawienie w komunikatach o błędach informacji wrażliwych, przechowywanie danych w chmurze bez odpowiednich mechanizmów kontroli zabezpieczeń, nieprawidłowe skonfigurowanie nagłówków HTTP, itp. Platforma Apigee udostępnia wiele mechanizmów, które umożliwiają kontrolowanie, zarządzanie, i monitorowanie konfiguracji zabezpieczeń, w tym przepływy współdzielone wielokrotnego użytku.

Współdzielony przepływ umożliwia deweloperom interfejsów API łączenie zasad i zasobów w grupę wielokrotnego użytku. Dzięki przechwytywaniu funkcji wielokrotnego użytku w jednym miejscu współdzielony przepływ pomaga zapewnić spójność, skrócić czas programowania i łatwiej zarządzać kodem. Możesz uwzględnić współdzielony przepływ w poszczególnych proxy interfejsów API lub pójść o krok dalej i umieścić współdzielone przepływy w punktach zaczepienia przepływu, aby automatycznie wykonywać logikę współdzielonego przepływu dla każdego proxy interfejsu API wdrożonego w tym samym środowisku co współdzielony przepływ.

Wersje Apigee zapewniają ochronę przed bibliotekami z lukami w zabezpieczeniach. Jeśli zostaną wykryte nowe luki w zabezpieczeniach, Apigee może opublikować dodatkowe poprawki lub aktualizacje. Publiczna chmura Edge jest automatycznie aktualizowana. Klienci korzystający z Edge for Private Cloud (lokalnie) muszą samodzielnie stosować poprawki produktu.

A7:2017 – cross-site scripting (XSS)

Cross-site scripting (XSS) umożliwia osobom atakującym wykonywanie skryptów w przeglądarkach internetowych użytkowników w celu kontrolowania sesji użytkowników , manipulowania witrynami lub złośliwego wpływania na użytkowników w inny sposób. Problemy z XSS nie są koniecznie związane z interfejsami API, ale Apigee udostępnia zasady ochrony przed zagrożeniami, które można wykorzystać do ochrony przed XSS w interfejsie API. Za pomocą wyrażeń regularnych, w zasadzie z zasadą RegularExpressionProtection lub zasadą JavaScript, sprawdzaj ładunek i wartości parametrów pod kątem JavaScriptu i innych ataków typu wstrzyknięcie.

CORS, jedno z powszechnie stosowanych rozwiązań dotyczących zasady tego samego pochodzenia, która jest egzekwowana przez wszystkie przeglądarki, można zaimplementować za pomocą zasady AssignMessage.

A8:2017 – niezabezpieczona deserializacja

Osoby atakujące mogą wykorzystywać luki w deserializacji do różnych rodzajów ataków, takich jak ataki typu replay, eskalacja uprawnień i wstrzyknięcie. Niezabezpieczona deserializacja może też umożliwiać zdalne wykonywanie kodu.

Apigee nie zaleca deserializacji. Zasady JSONThreatProtection i RegularExpressionProtection mogą jednak pomóc w ochronie przed złośliwymi ładunkami JSON. Zasady JavaScript można też używać do skanowania ładunków pod kątem złośliwych treści. Pamięć podręczna i inne zasady mogą służyć do ochrony przed atakami typu replay. Na poziomie infrastruktury platforma Apigee ma też wbudowane mechanizmy zabezpieczające, które chronią uruchomione procesy.

A9:2017 – używanie komponentów ze znanymi lukami w zabezpieczeniach

Ponieważ platformy, biblioteki i moduły działają z pełnym dostępem do wykonywania i CRUD, osoby atakujące mogą wykorzystywać luki w zabezpieczeniach komponentów do atakowania systemów.

Regularne wersje Apigee zapewniają ochronę przed lukami w zabezpieczeniach komponentów, zwłaszcza gdy zostaną wykryte konkretne luki. Publiczna chmura Apigee jest automatycznie aktualizowana , a Apigee powiadamia klientów Edge for Private Cloud, gdy dostępne są poprawki lokalne.

A10:2017 – niewystarczające logowanie i monitorowanie

Jeśli w systemach nie będziesz odpowiednio prowadzić logowania, monitorowania i zarządzania incydentami, osoby atakujące mogą przeprowadzać głębsze i dłuższe ataki na dane i oprogramowanie.

Apigee udostępnia kilka sposobów przeprowadzania logowania, monitorowania, obsługi błędów i logowania kontrolnego.

Logowanie

  • Komunikaty logów można wysyłać do Splunka lub innego punktu końcowego syslog za pomocą zasady MessageLogging.
  • Dane analityczne interfejsu API można pobierać za pomocą interfejsu Analytics API i importować lub eksportować do innych systemów.
  • W Edge for Private Cloud możesz użyć zasady MessageLogging, aby zapisywać dane w lokalnych plikach logów. Dostępne są też pliki logów z każdego z uruchomionych komponentów.
  • Zasady JavaScript można używać do synchronicznego lub asynchronicznego wysyłania komunikatów logów do punktu końcowego logowania REST.

Monitorowanie

  • Używaj interfejsu API Monitoring UI lub interfejsu API, aby regularnie monitorować interfejsy API i backendy oraz wywoływać alerty.
  • Używaj stanu monitorowania, aby regularnie monitorować backendy serwerów docelowych.
  • Apigee udostępnia zalecenia dotyczące monitorowania Edge for Private Cloud.
  • Apigee udostępnia też sprawdzone metody, które Twój zespół może wykorzystać do monitorowania programu API.

Obsługa błędów

Apigee oferuje zaawansowany i wszechstronny mechanizm obsługi błędów w przypadku proxy interfejsów API. Podobnie jak program w języku Java może przechwytywać wyjątki, proxy interfejsów API mogą przechwytywać błędy i określać, jak zwracać odpowiednie odpowiedzi klientom. Niestandardowa obsługa błędów Apigee umożliwia dodawanie funkcji, takich jak logowanie wiadomości, gdy wystąpi błąd.

Logi kontrolne

Platforma Apigee prowadzi dziennik kontrolny, który śledzi zmiany w proxy interfejsów API, usługach i historii organizacji. Ten dziennik jest dostępny w interfejsie lub za pomocą interfejsu Audits API.

Rozwiązania Apigee dotyczące luk w zabezpieczeniach OWASP z 2013 r.

Gdy OWASP zaktualizowała listę w 2017 r., niektóre luki w zabezpieczeniach z listy z 2013 r. zostały pominięte. Nadal stanowią one jednak zagrożenie. W kolejnych sekcjach opisujemy, jak radzić sobie z tymi zagrożeniami za pomocą Apigee.

A8:2013 – fałszowanie żądań z innych witryn (CSRF)

Żądania cross-site forgery umożliwiają osobom atakującym przekazywanie danych uwierzytelniających użytkownika, pliku cookie sesji, i innych danych do podatnej na ataki aplikacji internetowej przez HTTP, co powoduje, że aplikacja internetowa uważa żądania za prawidłowe żądania od użytkownika.

Wskazówki:

  • Jest to raczej problem z przeglądarką niż z usługą API. Możesz rozwiązać ten problem z luką w zabezpieczeniach za pomocą OpenID Connect, OAuth i innych technik.
  • Rozważ użycie technik HMAC, state, hash, nonce lub PKCE, aby zapobiec atakom typu forgery i replay ataki.

A10:2013 – niezweryfikowane przekierowania

Jeśli aplikacja internetowa wykonuje przekierowania, ale nie sprawdza, czy przekierowania wysyłają użytkowników do zaufanych, docelowych witryn, osoby atakujące mogą wysyłać użytkowników do złośliwych miejsc docelowych w celu przeprowadzenia phishingu, wykonania złośliwego oprogramowania i innych ataków.

Wskazówki:

  • Używaj OAuth i egzekwuj weryfikację przy każdym żądaniu.
  • Zapobiegaj nieoczekiwanym przekierowaniom 302, sprawdzając kody odpowiedzi w logice proxy interfejsu API i odpowiednio obsługując przekierowania.