OWASP – 10 najczęstszych zagrożeń

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

Ten dokument opisuje różne podejścia, których możesz używać w Apigee do rozwiązywania problemów z bezpieczeństwem zidentyfikowanych przez OWASP. Więcej informacji o dodatkowych podejściach dostępnych w Apigee znajdziesz w artykule 10 najlepszych opcji zapobiegania atakom w Google Cloud według OWASP w 2021 r..

Omówienie

Ekosystemy interfejsów API są narażone na różne ataki zarówno ze strony klientów zewnętrznych, jak 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ą zdawać sobie sprawę z tych wyzwań i rozwiązywać je podczas tworzenia i używania interfejsów API.

OWASP to otwarta społeczność, która pomaga organizacjom w rozwijaniu, zakupie i utrzymywaniu zaufanych aplikacji i interfejsów API. W ramach projektu OWASP API Security organizacja OWASP publikuje najważniejsze zagrożenia dla bezpieczeństwa aplikacji internetowych i interfejsów API REST oraz podaje rekomendacje dotyczące radzenia sobie z tymi zagrożeniami.

W ramach Apigee warstwa proxy interfejsu API może wykrywać, blokować i zgłaszać błędne żądania interfejsu API od klienta, zanim zostaną one przetworzone w systemach backendu. Dzięki temu można ograniczyć ryzyko i chronić usługi. Błędne żądania mogą zawierać dowolny komponent protokołu HTTP na poziomie aplikacji:

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

Błędne żądania interfejsu API mogą pochodzić od znanych lub nieznanych klientów, którzy są zewnętrznymi lub wewnętrznymi deweloperami albo złośliwymi botami.  Tego typu żądania stanowią większość zagrożeń OWASP, ale istnieją dodatkowe komponenty warstwy pośredniczącej interfejsu API, które mogą ograniczać ryzyko, takie jak maskowanie danych, rejestrowanie, administracja itp.

Inteligentna platforma do zarządzania interfejsami API firmy Apigee umożliwia bezproblemowe rozwiązywanie najczęstszych zagrożeń związanych z bezpieczeństwem interfejsów API według OWASP, ponieważ pozwala projektować interfejsy API z uwzględnieniem użytkowników i ich potrzeb oraz łączyć je z systemami backendowymi. Poniżej znajdziesz listę zasad i ustawień zalecanych przez Apigee w przypadku najczęstszych zagrożeń OWASP dla REST.

Rozwiązania Apigee dotyczące 10 najczęstszych zagrożeń OWASP z 2017 r.

W przypadku tworzenia i zabezpieczania aplikacji internetowych istnieje wiele problemów związanych z bezpieczeństwem. OWASP opublikował listę 10 najczęstszych zagrożeń dla bezpieczeństwa aplikacji internetowych w 2017 roku.  Aplikacja internetowa składa się z wielu części, ale większość nowoczesnych aplikacji internetowych w dużej mierze opiera się na interfejsach API REST.  Apigee nie obsługuje wszystkich potrzeb bezpieczeństwa aplikacji internetowej, ale może odgrywać kluczową rolę w zabezpieczaniu interfejsów API REST. Poniżej znajdziesz najważniejsze zagrożenia bezpieczeństwa według OWASP wraz z opisami sposobów, w jakie możesz używać Apigee do ich zwalczania.

A1:2017 – wstrzyknięcie

Aby chronić przed niesprawdzonymi danymi, takimi jak SQL, NoSQL, LDAP i JavaScript, które mogą skutkować wykonaniem niezamierzonych poleceń lub nieautoryzowanym dostępem do danych, Apigee udostępnia kilka zasad weryfikacji danych wejściowych. Ma to na celu sprawdzenie, czy wartości podane przez klienta są zgodne z oczekiwaniami, zanim dozwoli na dalsze przetwarzanie. Apigee Edge, działając jako serwer dla przychodzących żądań interfejsu API, sprawdza, czy struktura ładunku mieści się w akceptowalnym zakresie, co nazywamy również sprawdzaniem limitu. Możesz skonfigurować serwer proxy interfejsu API, aby rutyna sprawdzania poprawności danych przekształcała dane wejściowe w celu usuwania niebezpiecznych sekwencji znaków i zastępowania ich bezpiecznymi wartościami.

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

Sprawdzanie typów treści:

A2:2017 – Nieprawidłowe uwierzytelnianie i zarządzanie sesją

Atakujący mogą uzyskać 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 wdrożeniem niż z usługą.  Apigee udostępnia zasady dotyczące VerifyApiKey, OAuth i tokenów sieciowych JSON (JWT), które pomagają chronić 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 klienta po prostu przedstawia klucz interfejsu API w żądaniu, a Apigee Edge za pomocą reguły dołączonej do serwera proxy interfejsu API sprawdza, czy klucz interfejsu API jest zatwierdzony w przypadku zasobu, którego dotyczy żądanie.

Apigee zapewnia obsługę generowania i weryfikacji kluczy interfejsu API. Apigee generuje klucz i tajny klucz API, gdy aplikacja programisty zostanie utworzona i zatwierdzona, a następnie powiązana z co najmniej jedną usługą API.

Termin „klucze API” może czasem oznaczać różne rzeczy. Gdy w Apigee powstaje relacja między aplikacją a produktem, Apigee generuje identyfikator klienta i tajny klucz klienta. Niektórzy używają określenia „klucz API” na określenie zarówno identyfikatora, jak i tajemnego klucza. Niektórzy używają nazwy klienta jako klucza API. W interfejsie Edge zobaczysz „klucz konsumenta” i „klucz tajny konsumenta”.

W zasadzie weryfikacji klucza API weryfikowany jest tylko identyfikator klienta, czyli „klucz klienta”. Deweloperzy otrzymują klucz dla konsumenta, gdy rejestrują aplikację w usłudze Apigee i kojarzą ją z produktem API. Deweloperzy umieszczają klucz klienta w wywołaniach aplikacji do serwerów proxy interfejsu API, które są częścią produktu interfejsu API.

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

W przypadku typów przyznawania uprawnień OAuth używane są zarówno identyfikator, jak i klucz klienta.

OAuth 2.0

Ramy autoryzacji OAuth 2.0 umożliwiają aplikacji innej firmy uzyskanie ograniczonego dostępu do usługi HTTP, albo w imieniu właściciela zasobu przez zorganizowanie interakcji zatwierdzenia między właścicielem zasobu a usługą HTTP, albo przez zezwolenie aplikacji innej firmy na uzyskanie dostępu we własnym imieniu.

Zasady OAuth 2.0 w usłudze Apigee umożliwiają implementowanie i dostosowywanie 4 typów uprawnień OAuth 2.0. Wymuszanie tokenów dostępu OAuth można stosować za pomocą zasad OAuthv2. Konsument musi być zarejestrowany i mieć zatwierdzoną aplikację, która przyznała mu dostęp do interfejsu API. W zamian otrzyma identyfikator klienta API i tajny klucz klienta. Użytkownik musi przejść proces uwierzytelniania za pomocą jednego z OAuth grantów, co spowoduje przyznanie mu nieprzezroczystego tokena dostępu. Można go używać do kontrolowania dostępu do interfejsu API.

JWT

Tokeny sieciowe JSON (JWT) są często używane do udostępniania roszczeń lub twierdzeń między połączonymi aplikacjami. Apigee zapewnia obsługę JWT za pomocą 3 reguł.

  • GenerateJWT tokens (supports HS256 and RS256 signature)
  • ValidateJWT
  • Dekodowanie tokenów JWT bez ich weryfikacji

A3:2017 – Wyciek danych wrażliwych

Atakujący celują w dane poufne, takie jak dane karty kredytowej, numery PESEL, dane logowania, informacje umożliwiające identyfikację i numery identyfikacyjne podatnika, aby dokonywać kradzieży tożsamości, kradzieży pieniędzy, oszustw i innych przestępstw. Aplikacje internetowe muszą stosować szyfrowanie zarówno w spoczynku, jak i podczas przesyłania, a także inne strategie, aby zapewnić ochronę danych wrażliwych.

TLS (Transport Layer Security, którego poprzednikiem jest SSL) to standardowa technologia zabezpieczeń służąca do nawiązywania szyfrowanego połączenia między serwerem internetowym a klientem internetowym, takim jak przeglądarka lub aplikacja. Apigee obsługuje zarówno szyfrowanie jednostronne, jak i dwustronne.

TLS w kierunku północnym (klient łączący się z interfejsem API działającym jako serwer) jest obsługiwany za pomocą konfiguracji hosta wirtualnego. Wirtualny host może być skonfigurowany pod kątem jednokierunkowego lub dwukierunkowego TLS.

TLS w kierunku południowym (apigee jako klient łączący się z usługą backendową) jest obsługiwany za pomocą konfiguracji serwera docelowego. Serwer docelowy można skonfigurować pod kątem szyfrowania pojedynczego lub obustronnego.

Apigee obsługuje wiele opcji konfiguracji TLS.

Wymuszanie dwukierunkowego TLS zapewnia, że klient używa certyfikatu, który został już dodany do Apigee. OWASP udostępnia też sprawdzone metody dotyczące TLS.

W wersji hybrydowej Apigee protokół TLS jest dostępny na wejściu za pomocą aliasu hosta, który jest podobny do hosta wirtualnego.

Oto wytyczne dotyczące zabezpieczania danych wrażliwych:

  • Używaj platformy, która obsługuje szyfrowanie jednostronne i dwustronne TLS, co zapewnia ochronę na poziomie protokołu.
  • Użyj zasad takich jak Zasady dotyczące funkcji przypisywania wiadomości i Zasady dotyczące kodu JavaScript, aby usunąć dane wrażliwe, zanim zostaną one zwrócone klientowi.
  • Używaj standardowych technik OAuth i rozważ dodanie HMAC, szyfrowania, stanu, nonce, PKCE lub innych technik, aby zwiększyć poziom uwierzytelniania w przypadku każdego żądania.
  • Użyj ustawień maskowania danych, aby ukryć dane wrażliwe w narzędziu Edge Trace.
  • Uważaj na przechowywanie w pamięci podręcznej danych wrażliwych (lub szyfruj dane wrażliwe, które są przechowywane w pamięci podręcznej). W Edge możesz szyfrować dane wrażliwe w spoczynku w mapach klucz-wartość.

A4:2017 – zewnętrzne elementy XML

Systemy lub aplikacje, które przetwarzają XML, muszą obsługiwać „odwołania do jednostek zewnętrznych” 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, hakerzy mogą je zhakować i wykorzystać do kradzieży danych lub przeprowadzania różnych ataków na system, takich jak ataki typu DoS.

Zasady dotyczące funkcji ExtractVariables w usłudze Apigee umożliwiają wyodrębnianie treści z żądania lub odpowiedzi oraz przypisywanie tych treści do zmiennej. Możesz wyodrębnić dowolną część wiadomości, w tym nagłówki, ścieżki URI, dane JSON/XML, parametry formularza i parametry zapytania. Reguły działają w ten sposób, że: 1. z pomocą wzorca tekstowego dopasowują treść wiadomości do wzorca; 2. po znalezieniu dopasowania ustawiają zmienną z określoną treścią wiadomości.

Apigee ma wbudowany w ramach platformy parsujący XML, który używa XPath do wyodrębniania danych. Zasady XMLThreatProtection chronią przed szkodliwymi ładunkami XML.

A5:2017 – Nieprawidłowa kontrola dostępu

Po zalogowaniu się i uzyskaniu dostępu do systemu należy wdrożyć odpowiednie mechanizmy autoryzacji, aby użytkownicy mogli zobaczyć i zrobić tylko to, co jest dozwolone. Bez silnych mechanizmów kontroli dostępu atakujący mogą przeglądać nieautoryzowane i często poufne dane lub w złośliwy sposób manipulować danymi i zachowaniem systemu.

Apigee obsługuje podejście wielowarstwowe do wdrażania kontroli dostępu, aby nieuprawnione osoby nie mogły wprowadzać nieuprawnionych zmian ani uzyskiwać dostępu do systemu.

Kontrola dostępu do interfejsu Edge

Kontrola dostępu do portalu dla deweloperów Apigee

  • Skonfiguruj logowanie jednokrotne u dostawcy tożsamości Twojej firmy.
  • Skonfiguruj kontrolę dostępu opartą na rolach (RBAC), aby zezwalać użytkownikom na dostęp tylko do funkcji i konfiguracji, których potrzebują na portalach dla deweloperów opartych na Drupalu.
  • Konfigurowanie portali dla deweloperów w celu wyświetlania określonych usług interfejsu 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 w czasie wykonywania kodu w Apigee

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

A6:2017-Security Misconfiguration

Niewłaściwą konfigurację zabezpieczeń łatwo przeoczyć, często dlatego, że administratorzy i programiści błędnie uważają, że systemy, których używają, są z założenia bezpieczne. Nieprawidłowa konfiguracja zabezpieczeń może wystąpić na wiele różnych sposobów, na przykład w postaci zaufania domyślnym konfiguracjom lub częściowym konfiguracjom, które mogą być niepewne, zezwalaniu na to, aby komunikaty o błędach zawierały informacje poufne, przechowywaniu danych w chmurze bez odpowiednich mechanizmów kontroli bezpieczeństwa, nieprawidłowej konfiguracji nagłówków HTTP itd. Platforma Apigee udostępnia wiele mechanizmów, które umożliwiają kontrolowanie, zarządzanie i monitorowanie konfiguracji zabezpieczeń, w tym wielokrotnie użytelnych wspólnych przepływów danych.

Współdzielony proces umożliwia deweloperom interfejsu API łączyć zasady i zasoby w grupę, którą można wielokrotnie używać. Dzięki umieszczeniu w jednym miejscu funkcji, które można ponownie wykorzystać, wspólny proces pomaga zapewnić spójność, skrócić czas rozwoju i ułatwić zarządzanie kodem. Możesz umieścić wspólny proces w poszczególnych proxy interfejsu API lub pójść o krok dalej i umieścić wspólne procesy w hakach przepływu, aby automatycznie wykonywać wspólną logikę przepływu dla każdego proxy interfejsu API wdrożonego w tym samym środowisku co wspólny proces.

Wersje produktów Apigee zapewniają ochronę przed bibliotekami z lukami w zabezpieczeniach. Jeśli zostaną znalezione nowe luki w zabezpieczeniach, Apigee może wydać dodatkowe łatki lub aktualizacje. Publiczna chmura Edge jest aktualizowana automatycznie. Klienci korzystający z Edge for Private Cloud (w lokalizacji klienta) muszą samodzielnie stosować poprawki do usługi.

A7:2017-Cross-Site Scripting (XSS)

Skryptowanie między witrynami (XSS) umożliwia atakującym uruchamianie skryptów w przeglądarkach użytkowników w celu kontrolowania ich sesji, manipulowania witrynami lub szkodliwego wpływu 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 (z użyciem polityki RegularExpressionProtection lub polityki JavaScript) sprawdzaj wartości ładunku i parametrów pod kątem JavaScriptu i innych ataków typu wstrzyknięcie.

CORS, które jest jednym z powszechnie stosowanych rozwiązań zasady jednego pochodzenia egzekwowanej przez wszystkie przeglądarki, może być implementowane za pomocą zasad dotyczących przypisywania wiadomości.

A8:2017 – Niebezpieczna deserializacja

Atakujący mogą wykorzystywać błędy w deserializacji do różnych typów ataków, takich jak odtwarzanie, podwyższanie uprawnień i wstrzykiwanie. Niebezpieczna deserializacja może też umożliwiać zdalne wykonywanie kodu.

Apigee nie zaleca deserializacji. Jednak zasady JSONThreatProtection i RegularExpressionProtection mogą pomóc w ochronie przed szkodliwymi ładunkami JSON. Zasady dotyczące JavaScriptu można też wykorzystać 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 polegającymi na odtwarzaniu. Na poziomie infrastruktury platforma Apigee ma też wbudowane zabezpieczenia, które chronią uruchomione procesy.

A9:2017 – Korzystanie z komponentów z znanymi lukami w zabezpieczeniach

Platformy, biblioteki i moduły działają z pełnym dostępem do wykonywania i modyfikowania danych, dlatego atakujący mogą wykorzystywać luki w zabezpieczeniach komponentów, aby atakować systemy.

Regularne wersje produktów Apigee zapewniają ochronę przed lukami w komponentach, zwłaszcza w przypadku wykrycia konkretnych luk. Usługa Apigee w chmurze publicznej jest aktualizowana automatycznie, a gdy dostępne są poprawki do zainstalowania na urządzeniach lokalnych, Apigee wysyła powiadomienia do klientów Edge for Private Cloud.

A10:2017 – Niewystarczające logowanie i monitorowanie

Jeśli w swoich systemach nie wykonujesz wystarczająco skutecznego rejestrowania, monitorowania i zarządzania incydentami, atakujący mogą przeprowadzać bardziej zaawansowane i długotrwałe ataki na dane i oprogramowanie.

Apigee umożliwia rejestrowanie, monitorowanie, obsługę błędów i rejestrowanie kontrolne na kilka sposobów.

Logowanie

  • Za pomocą zasad dotyczących rejestrowania wiadomości możesz wysyłać wiadomości logowania do Splunk lub innego punktu końcowego syslog.
  • Dane analityczne interfejsu API można pobierać za pomocą interfejsu API analityki, a potem importować lub eksportować do innych systemów.
  • W Edge for Private Cloud możesz używać zasady MessageLogging do zapisywania danych w lokalnych plikach dziennika. Dostępne są też pliki dziennika z każdego uruchomionego komponentu.
  • Zasady JavaScriptu można używać do synchronicznego lub asynchronicznego wysyłania komunikatów logowania do punktu końcowego logowania REST.

Monitorowanie

  • Korzystaj z interfejsu użytkownika lub interfejsu API Monitorowanie interfejsu API, aby regularnie monitorować interfejsy API, backendy i aplety.
  • Używaj monitorowania stanu, aby regularnie sprawdzać serwery docelowego backendu.
  • Apigee udostępnia rekomendacje dotyczące monitorowania Edge for Private Cloud.
  • Platforma Apigee udostępnia też sprawdzone metody, których Twój zespół może używać do monitorowania programu interfejsów API.

Obsługa błędów

Apigee oferuje zaawansowany i wszechstronny mechanizm obsługi błędów dla serwerów proxy interfejsu API. Podobnie jak program w języku Java może przechwytywać wyjątki, tak proxy interfejsu API mogą przechwytywać błędy i określać, jak zwracać odpowiednie odpowiedzi klientom. Dzięki niestandardowemu przetwarzaniu błędów w Apigee możesz dodawać funkcje, takie jak rejestrowanie wiadomości w przypadku wystąpienia błędu.

Logi kontrolne

Platforma Apigee prowadzi dziennik kontrolny, w którym śledzi zmiany w serwerach proxy interfejsu API, produktach i historii organizacji.  Ten dziennik jest dostępny przez interfejs użytkownika lub przez interfejs Audits API.

Rozwiązania Apigee na luki w zabezpieczeniach OWASP z 2013 r.

Gdy OWASP aktualizował swoją listę na rok 2017, niektóre luki z listy z 2013 r. zostały pominięte. Nadal stanowią one zagrożenie. W następnych sekcjach znajdziesz informacje o tym, jak radzić sobie z tymi zagrożeniami w usłudze Apigee.

A8:2013 – sfałszowanie żądania z innej witryny (CSRF)

Żądania fałszowania między witrynami umożliwiają atakującym przesyłanie danych uwierzytelniania użytkownika, pliku cookie sesji i innych danych do podatnej aplikacji internetowej przez HTTP, co powoduje, że aplikacja internetowa uważa te żądania za żądania pochodzące od użytkownika.

Wskazówki:

  • Jest to raczej problem z przeglądarką, a nie z interfejsem API. Możesz rozwiązać ten problem, stosując OpenID Connect, OAuth i inne techniki.
  • Aby zapobiegać fałszowaniu i atakom metodą powtórzenia, rozważ użycie technik HMAC, stanu, skrótu, nonce lub PKCE.

A10:2013 – Niezweryfikowane przekierowania i przekierowania do przodu

Jeśli aplikacja internetowa wykonuje przekierowania, ale nie weryfikuje, czy przekierowania te kierują użytkowników do zaufanych, docelowych witryn, hakerzy mogą przekierowywać użytkowników do złośliwych witryn, aby przeprowadzać phishing, uruchamiać złośliwe oprogramowanie i wykonywać inne ataki.

Wskazówki:

  • Używaj protokołu OAuth i wymagaj weryfikacji przy każdym żądaniu.
  • Zapobiegaj nieoczekiwanym przekierowaniom 302, sprawdzając kody odpowiedzi w logice serwera proxy interfejsu API i odpowiednio obsługując przekierowania.