interfejsy programowania aplikacji internetowych (API) stanowią zaplecze dla nowoczesnych aplikacji internetowych i mobilnych. Połączenia Web API stanowią ponad 80% całego ruchu w sieci, a cyberprzestępcy coraz częściej kierują się na interfejsy API, więc zapewnienie bezpieczeństwa web API ma kluczowe znaczenie. REST API to najpopularniejszy typ interfejsu API dla usług internetowych. Zobaczmy, co możesz zrobić, aby zapewnić bezpieczeństwo REST API.
- Co to jest REST API?
- dwa poziomy bezpieczeństwa REST API
- zapewnienie bezpiecznego dostępu do API
- bezpieczeństwo połączenia
- Kontrola dostępu do API
- Autoryzacja użytkownika za pomocą kluczy API
- ograniczenia klientów interfejsu API
- Ochrona aplikacji, które ujawniają interfejsy API
- poufne dane w komunikacji API
- sprawdzanie poprawności typów zawartości
- nagłówki zabezpieczeń odpowiedzi
- Walidacja danych wejściowych
- dlaczego bezpieczeństwo REST API jest ważne
- o autorze
Co to jest REST API?
REST (skrót od REpresentational State Transfer) to styl architektury oprogramowania do tworzenia stron internetowych, zwykle używany z komunikacją HTTP. RESTful API (lub po prostu REST API) to interfejsy programowania aplikacji, które są zgodne z zasadami REST, umożliwiając klientom sieciowym i serwerom interakcję z ogromną różnorodnością zasobów internetowych. REST API używają standardowych czasowników HTTP (metod) i kodów stanu, aby zapewnić pewien poziom standaryzacji. Są one dostępne za pośrednictwem adresów URL HTTP i są szeroko stosowane w usługach internetowych.
Uwaga: Interfejsy API REST są bezstanowe jak sam protokół HTTP, co oznacza, że nie przechowują żadnych informacji o bieżących połączeniach lub sesjach. Usługi sieciowe RESTful umożliwiają dostęp do zasobów i manipulowanie nimi, a zarządzanie sesjami powinno być obsługiwane przez aplikację.
dwa poziomy bezpieczeństwa REST API
zanim przejdziemy do szczegółów technicznych, należy zwrócić uwagę na jedną ważną rzecz. Web API udostępnia interfejs aplikacji internetowej, więc musisz myśleć o bezpieczeństwie na dwóch poziomach: dostęp do API, a następnie dostęp do aplikacji.
na poziomie API potrzebne są odpowiednie uwierzytelnianie, autoryzacja, uprawnienia dostępu itd., aby zapewnić, że tylko upoważnieni klienci mogą korzystać z interfejsu i wykonywać tylko dozwolone operacje. Na poziomie aplikacji należy upewnić się, że punkty końcowe aplikacji (adresy URL używane do uzyskania dostępu do interfejsu) nie są podatne na ataki, które przedostają się przez interfejs lub go omijają.
zobaczmy, jak możesz zapewnić bezpieczeństwo REST API na tych dwóch poziomach. Szczegółowe omówienie najlepszych praktyk bezpieczeństwa API znajduje się w arkuszu oszukiwania bezpieczeństwa OWASP REST.
zapewnienie bezpiecznego dostępu do API
Większość interfejsów API sieci web jest narażona na działanie Internetu, dlatego potrzebują odpowiednich mechanizmów bezpieczeństwa, aby zapobiec nadużyciom, chronić poufne dane i zapewnić dostęp do nich tylko uwierzytelnionym i autoryzowanym użytkownikom.
bezpieczeństwo połączenia
bezpieczeństwo rozpoczyna się od samego połączenia HTTP. Bezpieczne interfejsy API REST powinny dostarczać tylko punkty końcowe HTTPS, aby zapewnić szyfrowanie całej komunikacji API przy użyciu protokołu SSL / TLS. Umożliwia to klientom uwierzytelnianie usługi i chroni poświadczenia API i przesyłane dane.
Kontrola dostępu do API
wiele interfejsów API sieci web jest dostępnych tylko dla uwierzytelnionych użytkowników, na przykład dlatego, że są one prywatne lub wymagają rejestracji lub płatności. Ponieważ interfejsy API REST są bezpaństwowe, Kontrola dostępu jest obsługiwana przez lokalne punkty końcowe. Najczęstsze metody uwierzytelniania REST API to:
- podstawowe uwierzytelnianie HTTP: poświadczenia są wysyłane bezpośrednio w nagłówkach HTTP w kodowaniu Base64 bez szyfrowania. Jest to najprostsza metoda uwierzytelniania i najłatwiejsza do wdrożenia. Jest również najmniej bezpieczny, ponieważ poufne dane są przesyłane jako zwykły tekst, więc powinny być używane tylko w połączeniu z HTTPS.
- JSON Web Tokens (JWT): poświadczenia i inne parametry dostępu są wysyłane jako struktury danych JSON. Te tokeny dostępu mogą być podpisywane kryptograficznie i są preferowanym sposobem kontrolowania dostępu do interfejsów API REST. Zobacz ściągawkę OWASP JWT, aby uzyskać szybki przegląd tokenów internetowych JSON, i RFC 7519, aby uzyskać pełną specyfikację.
- OAuth: standardowe mechanizmy OAuth 2.0 mogą być używane do uwierzytelniania i autoryzacji. OpenID Connect umożliwia bezpieczne uwierzytelnianie poprzez OAuth 2.0. Na przykład interfejsy API Google używają OAuth 2.0 do uwierzytelniania i autoryzacji.
Autoryzacja użytkownika za pomocą kluczy API
klucze API zapewniają sposób kontrolowania dostępu do publicznych usług REST. Operatorzy publicznych usług sieciowych mogą używać kluczy API do wymuszania ograniczenia szybkości połączeń API i ograniczania ataków typu denial-of-service. W przypadku usług monetyzowanych organizacje mogą korzystać z kluczy API w celu zapewnienia dostępu na podstawie zakupionego planu dostępu.
ograniczenia klientów interfejsu API
aby zminimalizować zagrożenia bezpieczeństwa, operatorzy usług REST powinni ograniczyć łączenie klientów do minimum funkcji wymaganych dla usługi. Zaczyna się to od ograniczenia obsługiwanych metod HTTP, aby upewnić się, że źle skonfigurowani lub złośliwi klienci nie mogą wykonywać żadnych działań poza specyfikacją API i dozwolonym poziomem dostępu. Na przykład, jeśli API zezwala tylko na żądania GET, POST i inne typy żądań powinny zostać odrzucone z kodem odpowiedzi 405 metoda niedozwolona.
Ochrona aplikacji, które ujawniają interfejsy API
gdy Klient ma legalny dostęp, musisz chronić podstawową aplikację internetową przed zniekształconymi i złośliwymi wejściami. Wywołania i odpowiedzi interfejsu REST API mogą również zawierać poufne dane, które muszą być kontrolowane.
poufne dane w komunikacji API
wywołania API często zawierają poświadczenia, klucze API, tokeny sesji i inne poufne informacje. Dane te mogą być przechowywane w logach serwera WWW i wyciekać, jeśli dzienniki są dostępne dla cyberprzestępców. Aby uniknąć wycieku poufnych informacji, Usługi sieciowe RESTful powinny zawsze wysyłać je w nagłówkach żądań HTTP lub w treści żądania (dla żądań POST I PUT).
sprawdzanie poprawności typów zawartości
kontynuując temat ograniczeń klienta API, usługi REST powinny precyzyjnie definiować dozwolone typy zawartości i odrzucać żądania, które nie mają prawidłowych deklaracji w nagłówkach HTTP. Oznacza to dokładne określenie dozwolonych typów zarówno w nagłówku Content-Type
, jak i w nagłówku Accept
, wraz z zestawem znaków (jeśli to możliwe). Jeśli usługa zawiera JavaScript (lub inny kod skryptu), należy upewnić się, że typ zawartości w nagłówku jest taki sam jak w treści żądania, na przykład application/javascript
. Pomaga to zapobiegać atakom typu header injection.
nagłówki zabezpieczeń odpowiedzi
można ustawić dodatkowe nagłówki zabezpieczeń HTTP, aby jeszcze bardziej ograniczyć typ i zakres żądań. Należą do nich X-Content-Type-Options: nosniff
, aby zapobiec atakom XSS opartym na sniffingu MIME i X-Frame-Options: deny
, aby zapobiec próbom klikania w starszych przeglądarkach.
jeśli usługa nie obsługuje połączeń między domenami, powinna wyłączyć CORS (cross-origin resource sharing) w nagłówkach odpowiedzi. Jeśli takie wywołania są oczekiwane, nagłówki CORS powinny precyzyjnie określać dozwolone pochodzenie.
Walidacja danych wejściowych
interfejsy API są przeznaczone do automatycznego dostępu bez interakcji z użytkownikiem, dlatego szczególnie ważne jest upewnienie się, że wszystkie dane wejściowe są poprawne i oczekiwane. Wszelkie żądania, które nie są zgodne ze specyfikacją API, muszą zostać odrzucone. Zastosowanie mają typowe wytyczne dotyczące najlepszych praktyk w zakresie walidacji danych wejściowych:
- traktuj wszystkie parametry, obiekty i inne dane wejściowe jako niezaufane.
- użyj wbudowanej funkcji sprawdzania poprawności, jeśli jest dostępna.
- Sprawdź rozmiar żądania, długość i typ zawartości.
- używaj silnego pisania dla parametrów API (jeśli są obsługiwane).
- aby zapobiec wstrzyknięciu SQL, unikaj ręcznego tworzenia zapytań – zamiast tego użyj zapytań sparametryzowanych.
- Whitelist wartości parametrów i string inputs wszędzie tam, gdzie to możliwe.
- Rejestruj wszystkie błędy weryfikacji wejściowej, aby wykryć próby wypełniania poświadczeń.
dlaczego bezpieczeństwo REST API jest ważne
interfejsy API sieci Web są podstawą nowoczesnego projektowania stron internetowych i urządzeń mobilnych. Umożliwiają one aplikacjom i usługom komunikowanie się i wymianę danych między platformami sprzętowymi i programowymi. Podczas gdy inne formaty API są nadal w użyciu (na przykład SOAP), API REST są obecnie dominującym typem, stanowiąc ponad 80% wszystkich publicznych API internetowych. Zapewniają one zaplecze dla większości aplikacji mobilnych i urządzeń IoT oraz umożliwiają łatwą integrację między systemami i aplikacjami.
ponieważ używają tych samych technologii co aplikacje internetowe, interfejsy API REST mogą być podatne na te same ataki. Jednocześnie interfejsy API nie są przeznaczone do ręcznego dostępu, więc mogą być trudne do przetestowania, zwłaszcza jeśli niektóre punkty końcowe i funkcje są nieudokumentowane. Testowanie zabezpieczeń API wymaga precyzyjnych zautomatyzowanych narzędzi, aby zapewnić pełne pokrycie. Netsparker zapewnia pełną obsługę skanowania luk w REST API za pomocą różnych metod uwierzytelniania i automatycznego przepisywania adresów URL.
zapoznaj się z dokumentacją strony testowej Netsparker REST API, aby uzyskać pełne dane techniczne i przeczytaj nasz pełny artykuł na temat skanowania interfejsów API REST w poszukiwaniu luk w zabezpieczeniach za pomocą Netsparker.
o autorze
Autor treści technicznych w Netsparker. Wykorzystując swoje doświadczenie jako dziennikarz IT i Tłumacz techniczny, dokłada wszelkich starań, aby na blogu I stronie internetowej Netsparker udostępnić bezpieczeństwo sieci szerszej publiczności.