OWASP – 10 najczęstszych zagrożeń

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

W tym dokumencie opisano różne podejścia, które można wykorzystać w Apigee do rozwiązywania problemów z lukami w zabezpieczeniach zidentyfikowanych przez OWASP. Dodatkowe metody działania opisane w dokumentacji Apigee znajdziesz w artykule o opcjach łagodzenia skutków zagrożenia OWASP Top 10 w 2021 r. w Google Cloud (w języku angielskim).

Przegląd

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

OWASP to otwarta społeczność, która pomaga organizacjom w tworzeniu, kupowaniu i utrzymywaniu zaufanych aplikacji oraz interfejsów API. W ramach projektu OWASP API Security organizacja OWASP publikuje najważniejsze zagrożenia dla aplikacji internetowych i interfejsów API typu REST oraz udostępnia zalecenia dotyczące radzenia sobie z nimi.

Dzięki Apigee warstwa serwera proxy interfejsu API może wykrywać, blokować i zgłaszać zniekształcone żądania interfejsu API wysyłane przez klienta, zanim zostaną one przetworzone w systemach backendu. Pozwala to ograniczyć ryzyko i chronić usługi. Żądania z nieprawidłowym formatem mogą zawierać dowolny komponent wchodzący w skład protokołu HTTP na poziomie aplikacji:

  • URL
  • nagłówków,
  • Ścieżka
  • Ładunek

Nieprawidłowe żądania do interfejsu API mogą pochodzić od znanych lub nieznanych klientów utworzonych przez zewnętrznych programistów, wewnętrznych programistów lub złośliwe boty. Te typy żądań stanowią większość zagrożeń OWASP, ale istnieją dodatkowe komponenty bazowej warstwy serwera proxy interfejsu API, które mogą zmniejszyć ryzyko, na przykład maskowanie danych, logowanie, administrowanie itp.

Inteligentna platforma Apigee do zarządzania interfejsami API ułatwia usuwanie najważniejszych luk w zabezpieczeniach interfejsu OWASP API, gdy projektujesz interfejsy API i łączysz je z systemami backendu w sposób skoncentrowany na użytkowaniu. Poniżej znajduje się lista zasad i konfiguracji rekomendowanych przez Apigee w przypadku najczęstszych zagrożeń REST OWASP.

Rozwiązania Apigee na listę OWASP Top 10 w 2017 roku

Podczas tworzenia i zabezpieczania aplikacji internetowych pojawia się wiele problemów z bezpieczeństwem. Organizacja OWASP opublikowała listę 10 największych zagrożeń OWASP Security 2017 dla aplikacji internetowych. Aplikacja internetowa składa się z wielu elementów, ale większość nowoczesnych aplikacji internetowych w dużym stopniu opiera się na interfejsach API REST. Apigee nie jest przeznaczone do obsługi wszystkich potrzeb w zakresie bezpieczeństwa aplikacji internetowych, 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 wykorzystania Apigee do ochrony przed tymi zagrożeniami.

A1:2017 – Wstrzyknięcie

Aby chronić się przed wstrzykiwaniem danych niezaufanych, takich jak SQL, NoSQL, LDAP czy JavaScript, co może skutkować wykonaniem niezamierzonych poleceń lub nieautoryzowanym dostępem do danych, Apigee udostępnia kilka zasad weryfikacji danych wejściowych, aby sprawdzić, czy wartości podane przez klienta są zgodne z oczekiwaniami, zanim możliwe będzie dalsze przetwarzanie. Apigee Edge, działając jako serwer dla przychodzących żądań do interfejsu API, sprawdza, czy struktura ładunku mieści się w akceptowalnym zakresie. Jest to tzw. kontrola limitu. Możesz skonfigurować serwer proxy interfejsu API, tak aby procedura weryfikacji danych wejściowych przekształciła dane wejściowe, usuwając ryzykowne sekwencje znaków i zastępując je bezpiecznymi wartościami.

Na platformie Apigee można zweryfikować dane wejściowe na kilka sposobów:

Zweryfikuj typy treści:

A2:2017 – Uszkodzone uwierzytelnianie i zarządzanie sesjami

Hakerzy mogą uzyskać dostęp do haseł, tokenów sesji i kluczy, aby podszywać się pod innych użytkowników, wykorzystując błędy implementacji w aplikacjach. Problem dotyczy raczej wdrożenia, a nie usługi. Apigee udostępnia zasady VerificationApiKey, OAuth i JSON Web Token (JWT), które pomagają chronić przed tą luką w zabezpieczeniach.

Weryfikacja klucza interfejsu API

Weryfikacja klucza interfejsu API to najprostsza forma zabezpieczeń aplikacji, którą można skonfigurować pod kątem interfejsu API. Aplikacja kliencka po prostu przedstawia w swoim żądaniu klucz interfejsu API, a następnie Apigee Edge za pomocą zasady powiązanej z serwerem proxy interfejsu API sprawdza, czy klucz interfejsu API jest w stanie zatwierdzenia dla żądanego zasobu.

Apigee zapewnia obsługę generowania i walidacji kluczy interfejsu API. Apigee generuje klucz i tajny klucz interfejsu API, gdy zostaje utworzona i zatwierdzona aplikacja dewelopera, która jest połączona z co najmniej jedną usługą API.

Termin „klucze interfejsu API” może czasem oznaczać różne rzeczy. Gdy w Apigee powstaje relacja między aplikacją i usługą, Apigee generuje identyfikator klienta i tajny klucz klienta. W niektórych kluczach API określane są zarówno identyfikator, jak i obiekt tajny. W innych przypadkach identyfikator klienta jest nazywany kluczem interfejsu API. W interfejsie użytkownika Edge zobaczysz „klucz klienta” i „Tajny klucz klienta”.

W zasadzieVerifyAPIKey weryfikowany jest tylko identyfikator klienta, czyli „klucz klienta”. Deweloperzy otrzymują klucz klienta, gdy rejestrują aplikację w Apigee i powiążą ją z usługą API. Deweloperzy podają klucz klienta w wywołaniach serwera proxy interfejsu API, które są dołączone do usługi API.

Apigee obsługuje również możliwość importowania istniejących kluczy interfejsu API ze źródeł zewnętrznych.

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

OAuth 2.0

Platforma autoryzacji OAuth 2.0 umożliwia aplikacji zewnętrznej uzyskanie ograniczonego dostępu do usługi HTTP w imieniu właściciela zasobów przez współpracę w ramach zatwierdzania między właścicielem zasobu a usługą HTTP lub przez zezwolenie aplikacji zewnętrznej na uzyskanie dostępu w jej imieniu.

Stosowane przez Apigee zasady OAuth 2.0 umożliwiają wdrażanie i dostosowywanie 4 typów uwierzytelniania OAuth 2.0. Egzekwowanie tokenów dostępu OAuth można przeprowadzić za pomocą zasady OAuthv2. Klient musi być zarejestrowany i mieć zatwierdzoną aplikację, która przyznała mu dostęp do interfejsu API. Zwrotnie otrzyma on identyfikator klienta interfejsu API i tajny klucz klienta. Aby uwierzytelnić się, konsument musi przejść przez jedno z uwierzytelnień OAuth, co daje mu nieprzejrzysty token dostępu. Ten token może służyć do kontrolowania dostępu do interfejsu API.

JWT

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

  • Generowanie tokenów JWT (obsługuje podpis HS256 i RS256)
  • Weryfikowanie tokenów JWT
  • Dekodowanie tokenów JWT bez weryfikacji

A3:2017 – Ekspozycja danych wrażliwych

Hakerzy atakują dane wrażliwe, takie jak dane kart kredytowych, numery PESEL, dane logowania, informacje umożliwiające identyfikację i identyfikatory podatkowe, aby dokonać kradzieży tożsamości, kradzieży pieniędzy lub przestępstwa. Aplikacje internetowe muszą zaimplementować szyfrowanie zarówno w spoczynku, jak i podczas przesyłania, oraz inne strategie, aby zapewnić ochronę danych wrażliwych.

Protokół TLS (Transport Layer Security, którego poprzednik to SSL) to standardowa technologia zabezpieczeń do tworzenia zaszyfrowanego połączenia między serwerem WWW a klientem internetowym, takim jak przeglądarka lub aplikacja. Apigee obsługuje zarówno jednokierunkowe, jak i dwukierunkowe połączenie TLS.

Protokół TLS w kierunku północnym (klient łączący się z interfejsem API działającym jako serwer) jest obsługiwany przez konfigurację hosta wirtualnego. W przypadku hosta wirtualnego można skonfigurować jedno- lub dwukierunkowe szyfrowanie TLS.

Południowy protokół TLS (apigee jako klient łączący się z usługą backendu) jest obsługiwany przez konfigurację serwera docelowego. Serwer docelowy można skonfigurować na potrzeby jedno- lub dwukierunkowego protokołu TLS.

Apigee obsługuje wiele opcji konfiguracji TLS.

Dwukierunkowe wymuszanie TLS sprawia, że klient używa certyfikatu, który został już zarejestrowany w Apigee. OWASP udostępnia też sprawdzone metody dotyczące protokołu TLS.

W hybrydowym środowisku Apigee protokół TLS jest dostępny w ruchu przychodzącym przez alias hosta, co jest podobne do hosta wirtualnego.

Oto wskazówki dotyczące zabezpieczania danych wrażliwych:

  • Korzystaj z platformy obsługującej jedno- i dwukierunkowe szyfrowanie TLS, które będzie zabezpieczać na poziomie protokołu.
  • Aby usunąć dane wrażliwe przed zwróceniem ich do klienta, użyj takich zasad, jak zasada AssignMessage i zasady JavaScript.
  • Użyj standardowych technik OAuth i rozważ dodanie HMAC, hasz, stanu, liczby jednorazowej, PKCE lub innych technik, aby poprawić poziom uwierzytelniania każdego żądania.
  • Aby zamaskować dane wrażliwe w narzędziu Edge Trace, użyj ustawień maskowania danych.
  • Zachowaj ostrożność, aby przechowywać w pamięci podręcznej wszelkie dane wrażliwe (lub szyfrować dane wrażliwe przechowywane w pamięci podręcznej). W Edge możesz szyfrować dane wrażliwe w spoczynku w mapach par klucz-wartość.

A4:2017 – Zewnętrzne jednostki XML

Systemy lub aplikacje, które przetwarzają XML, muszą obsługiwać „odwołania do encji zewnętrznych” w formacie XML – odwołania do plików lub danych, które podczas przetwarzania XML są zastępowane rzeczywistymi danymi. Jeśli aplikacje lub procesory XML są stare lub słabo zaimplementowane, hakerzy mogą zhakować dane i wykorzystać je do kradzieży informacji lub przeprowadzania różnego rodzaju ataków na system, np. typu DoS.

Zasada wyodrębniania zmiennych w Apigee umożliwia wyodrębnianie treści z żądania lub odpowiedzi i przypisanie tej treści 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 stosowanie wzorca tekstowego do treści wiadomości, a po znalezieniu dopasowania ustawienie zmiennej z określoną treścią wiadomości.

Apigee ma wbudowany parser XML, który jest częścią platformy, która wyodrębnia dane za pomocą XPath. Zawiera też zasadę XMLThreatProtection, która zabezpiecza przed złośliwymi ładunkami XML.

A5:2017 – Uszkodzona kontrola dostępu

Gdy użytkownicy zalogują się i uzyskają dostęp do systemu, należy zastosować odpowiednie mechanizmy autoryzacji, aby mogli wyświetlać i wykonywać tylko te czynności, do których są dozwolone. Bez silnej kontroli dostępu hakerzy mogą przeglądać nieautoryzowane i często poufne dane lub złośliwie manipulować danymi i zachowaniem systemu.

Apigee obsługuje warstwowe podejście do wdrażania kontroli dostępu, które uniemożliwia nieuczciwym podmiotom wprowadzanie nieautoryzowanych zmian lub uzyskiwanie dostępu do systemu.

Kontrola dostępu do interfejsu użytkownika Edge

Kontrola dostępu do portalu dla programistów Apigee

  • Skonfiguruj logowanie jednokrotne przy użyciu dostawcy tożsamości swojej firmy.
  • Skonfiguruj kontrolę dostępu opartą na rolach, aby zezwolić użytkownikom na dostęp tylko do tych funkcji i konfiguracji, których potrzebują w portalach dla programistów opartych na platformie Drupal.
  • Skonfiguruj portale dla programistów, aby wyświetlać określone usługi API zgodnie z rolą użytkownika.
  • Skonfiguruj portal tak, aby wyświetlał lub ukrywał treści na podstawie roli użytkownika.

Kontrola dostępu do interfejsu API Apigee w środowisku wykonawczym

  • Dostęp do interfejsów API można wymuszać za pomocą kluczy interfejsu API, tokenów OAuth, zakresów OAuth, certyfikatów i innych technik.
  • Dostawca interfejsu API określa, które zasoby są dostępne, definiując usługę interfejsu API. Dostęp jest przyznawany ręcznie w interfejsie użytkownika, przez interfejs API zarządzania lub przez portal dla programistów. Gdy aplikacja dewelopera otrzymuje dostęp do usługi API, otrzymuje identyfikator klienta i tajny klucz używane w procesie uwierzytelniania.
  • Apigee może integrować się z dowolnym dostawcą tożsamości na potrzeby protokołu OAuth.
  • Apigee może generować tokeny JWT lub 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ń

Błędy w konfiguracji zabezpieczeń łatwo przeoczyć, często dlatego, że administratorzy i deweloperzy błędnie wierzą, że używane przez nich systemy są z natury bezpieczne. Błędy w konfiguracji zabezpieczeń mogą wystąpić na wiele różnych sposobów. Może to być na przykład zaufanie konfiguracji domyślnej lub utworzenie częściowych konfiguracji, które mogą być niezabezpieczone, zezwolenie na wyświetlanie komunikatów o błędach zawierających poufne dane, przechowywanie danych w chmurze bez odpowiednich opcji zabezpieczeń, błędne skonfigurowanie nagłówków HTTP. Platforma Apigee udostępnia wiele mechanizmów umożliwiających kontrolowanie i monitorowanie konfiguracji zabezpieczeń oraz zarządzanie nimi, w tym m.in. przepływy współdzielone wielokrotnego użytku.

W ramach wspólnego procesu deweloperzy interfejsów API mogą łączyć zasady i zasoby w grupę wielokrotnego użytku. Dzięki zbieraniu w jednym miejscu funkcji wielokrotnego użytku, wspólny przepływ pomaga zapewnić spójność, skrócić czas programowania i ułatwić zarządzanie kodem. Możesz uwzględnić przepływ wspólny w poszczególnych serwerach proxy interfejsu API lub zrobić krok dalej i umieścić współdzielone przepływy w punktach zaczepienia przepływu, aby automatycznie uruchamiać logikę wspólnego przepływu dla każdego serwera proxy interfejsu API wdrożonego w tym samym środowisku co przepływ współdzielony.

Wersje usługi Apigee zapewniają ochronę przed bibliotekami z lukami w zabezpieczeniach. Apigee może publikować dodatkowe poprawki lub aktualizacje w przypadku wykrycia nowych luk w zabezpieczeniach. Poprawki w chmurze publicznej na serwerach brzegowych są instalowane automatycznie. Klienci korzystający z Edge for Private Cloud (lokalnie) muszą samodzielnie stosować poprawki usług.

A7:2017 – obsługa skryptów między witrynami (XSS)

Skrypty cross-site scripting (XSS) umożliwiają hakerom uruchamianie skryptów w przeglądarkach użytkowników w celu kontrolowania sesji użytkowników, manipulowania witrynami lub wyrządzania szkody na kontach użytkowników w inny sposób. Problemy z XSS nie muszą być związane z interfejsami API, ale Apigee zapewnia zasady ochrony przed zagrożeniami, których można użyć do ochrony przed XSS w interfejsie API. Korzystając z wyrażeń regularnych, korzystając z zasady RegularExpressionProtection lub JavaScriptu, sprawdzaj ładunek i wartości parametrów pod kątem JavaScriptu i innych ataków typu wstrzyknięcie.

CORS, jedno z najczęściej stosowanych rozwiązań zasady dotyczącej tego samego pochodzenia egzekwowanej przez wszystkie przeglądarki, można wdrożyć za pomocą zasady AssignMessage.

A8:2017 – Niebezpieczna deserializacja

Hakerzy mogą wykorzystać błędy deserializacji w przypadku różnych typów ataków, takich jak ponowne odtwarzanie, eskalacja uprawnień czy wstrzykiwanie. Niezabezpieczona deserializacja może też umożliwić zdalne wykonywanie kodu.

Apigee nie zaleca deserializacji. Zasady JSONThreatProtection i RegularExpressionProtection mogą jednak ułatwiać ochronę przed złośliwymi ładunkami JSON. Zasada JavaScript może też służyć do skanowania ładunków pod kątem szkodliwych treści. Pamięć podręczna i inne zasady mogą służyć do ochrony przed atakami typu replay. Na poziomie infrastruktury platforma Apigee ma również wbudowane bariery chroniące uruchomione procesy.

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

Platformy, biblioteki i moduły działają z pełnym wykonaniem i dostępem do CRUD, więc hakerzy mogą wykorzystać luki w zabezpieczeniach komponentów podczas ataku na systemy.

Regularne wersje usługi Apigee zapewniają ochronę przed lukami w zabezpieczeniach komponentów, zwłaszcza w przypadku wykrycia określonych luk w zabezpieczeniach. Poprawka w chmurze publicznej Apigee jest stosowana automatycznie, a Apigee powiadamia Edge dla klientów Private Cloud, gdy dostępne są lokalne poprawki do zainstalowania.

A10:2017 – Niewystarczające logowanie i monitorowanie

Jeśli nie będziesz prawidłowo rejestrować, monitorować i zarządzać incydentami w swoich systemach, hakerzy mogą przeprowadzać głębsze i dłuższe ataki na dane i oprogramowanie.

Apigee ma kilka sposobów na logowanie, monitorowanie, obsługę błędów i logowanie kontrolne.

Logowanie

  • Komunikaty logu można wysyłać do Splunk lub innego punktu końcowego Syslog przy użyciu zasady MessageLogging.
  • Dane analityczne dotyczące interfejsów API można pobierać za pomocą interfejsu analytics API oraz importować lub eksportować do innych systemów.
  • W Edge for Private Cloud możesz użyć zasady MessageLogging, aby zapisywać dane w lokalnych plikach dziennika. Dostępne są także pliki dziennika z każdego z uruchomionych komponentów.
  • Zasada JavaScript może służyć do wysyłania komunikatów logu do punktu końcowego logowania REST synchronicznie lub asynchronicznie.

Monitorowanie

  • Używaj interfejsu API lub monitorowania interfejsów API Monitorowania interfejsów API, aby regularnie sprawdzać interfejsy API i backendy oraz aktywować wiadomości ale.
  • Używaj monitorowania stanu, aby regularnie sprawdzać backendy serwera docelowego.
  • Apigee udostępnia rekomendacje dotyczące monitorowania Edge w chmurze Private Cloud.
  • Apigee udostępnia też sprawdzone metody, które mogą wykorzystać Twój zespół do monitorowania programu interfejsów API.

Obsługa błędów

Apigee oferuje zaawansowany, uniwersalny mechanizm obsługi błędów na serwerach proxy interfejsu API. Podobnie jak program w Javie wychwytuje wyjątki, serwery proxy interfejsów API mogą wychwytywać błędy i określać, jak zwracać odpowiednie odpowiedzi klientom. Niestandardowa obsługa błędów Apigee umożliwia dodawanie funkcji takich jak logowanie komunikatów, gdy wystąpi błąd.

Logi kontrolne

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

Rozwiązania Apigee w przypadku luk w zabezpieczeniach OWASP w 2013 roku

Podczas aktualizacji listy OWASP na 2017 r. niektóre luki w zabezpieczeniach z 2013 roku zostały pominięte. Nadal są uznawane za ważne zagrożenia. W sekcjach poniżej dowiesz się, jak radzić sobie z tymi zagrożeniami za pomocą Apigee.

A8:2013 – Oszustwo oparte na żądaniach w różnych witrynach (CSRF)

Żądania dotyczące oszustw z innych witryn umożliwiają osobom przeprowadzającym atak przekazywanie danych uwierzytelniających użytkownika, pliku cookie sesji i innych danych do podatnej na ataki aplikacji internetowej przez HTTP, przez co aplikacja internetowa ma wrażenie, że żądania są uprawnionymi żądaniami od użytkownika.

Wskazówki:

  • Problem dotyczy raczej przeglądarki, a nie interfejsu API. Możesz usunąć tę lukę w zabezpieczeniach, korzystając z OpenID Connect, OAuth i innych technik.
  • Rozważ użycie technik HMAC, stanu, haszowania, liczby jednorazowej lub PKCE, aby zapobiegać sfałszowaniu i powtarzaniu ataków.

A10:2013 – Niezweryfikowane przekierowania i przekierowania

Jeśli aplikacja internetowa przeprowadza przekierowania, ale nie sprawdza, czy przekierowania odsyłają użytkowników do zaufanych, przeznaczonych dla wszystkich witryn, osoby przeprowadzające atak mogą kierować użytkowników do złośliwych miejsc, w których odbywa się wyłudzanie informacji, uruchamianie złośliwego oprogramowania i inne ataki.

Wskazówki:

  • Używaj protokołu OAuth i wymuszaj weryfikację przy każdym żądaniu.
  • Zapobiegaj niespodziewanym przekierowaniam 302, sprawdzając kody odpowiedzi w logice serwera proxy interfejsu API i odpowiednio obsługując przekierowania.