klucz API przesyłany bez HTTPS

Klucz API przesyłany bez HTTPS to luka bezpieczeństwa narażająca poświadczenie na przechwycenie podczas transmisji.

Dlaczego transmisja bez HTTPS ujawnia klucz API

Klucz API przesyłany bez HTTPS jest przekazywany przez zwykły protokół HTTP, bez warstwy szyfrującej TLS. W takiej komunikacji zawartość żądania może być odczytana przez urządzenia pośredniczące między klientem a serwerem, między innymi przez punkt dostępowy Wi-Fi, router, element infrastruktury sieciowej albo system pośredniczący w transmisji. Dotyczy to zarówno samego klucza, jak i adresu żądania, nagłówków HTTP oraz przesyłanych danych.

Klucz API często działa jak poświadczenie typu bearer, czyli osoba lub proces posiadający wartość klucza może przedstawić ją serwerowi i uzyskać dostęp przewidziany dla tego klucza. Przechwycenie nie musi więc oznaczać złamania algorytmu kryptograficznego. Wystarczy odczytanie żądania w trakcie transmisji. Jeżeli klucz został umieszczony w parametrze adresu URL, może dodatkowo trafić do historii przeglądarki, logów serwera proxy, narzędzi monitorujących lub innych zapisów diagnostycznych.

Różnica między HTTP a połączeniem chronionym TLS

HTTPS oznacza użycie HTTP nad protokołem TLS. Podczas nawiązywania połączenia TLS klient i serwer uzgadniają parametry ochrony, a serwer przedstawia certyfikat pozwalający klientowi zweryfikować jego tożsamość w ramach zaufanego łańcucha certyfikatów. Po ustanowieniu sesji dane aplikacyjne są szyfrowane i chronione przed niezauważoną modyfikacją podczas przesyłania.

Samo przekierowanie z adresu HTTP na HTTPS nie zabezpiecza pierwszego żądania. Jeżeli klient najpierw wysyła klucz do adresu HTTP, poświadczenie może zostać przechwycone przed wykonaniem przekierowania. Bezpieczniejsza konfiguracja wymaga używania adresu HTTPS od początku, poprawnego sprawdzania certyfikatu oraz ograniczenia komunikacji HTTP. Nagłówki HSTS mogą informować przeglądarkę, aby w przyszłości korzystała z HTTPS, ale nie zastępują prawidłowej konfiguracji serwera i nie chronią systemów, które nie respektują tego mechanizmu.

Skutki umieszczenia klucza w żądaniu

Najłatwiejszym do wykrycia przypadkiem jest klucz wpisany bezpośrednio w adres URL, na przykład jako parametr zapytania. Adresy są często rejestrowane w dziennikach dostępu, komunikatach błędów, systemach obserwowalności i narzędziach do analizy ruchu. Mogą również zostać ujawnione przez nagłówek Referer, jeżeli strona wykonująca żądanie przechodzi następnie do innego zasobu i polityka odsyłacza na to pozwala. Z tego powodu sekretów nie powinno się umieszczać w adresach, nawet gdy główny kanał komunikacji jest szyfrowany.

W praktyce klucz powinien być przekazywany wyłącznie przez HTTPS, zgodnie z mechanizmem przewidzianym przez dane API, na przykład w nagłówku autoryzacyjnym albo innym nagłówku wskazanym w dokumentacji usługi. Nie należy przesyłać go w kodzie JavaScript przeznaczonym dla nieufnego klienta, jeżeli klucz ma uprawnienia serwerowe. Ochrona transportu nie naprawia też wycieku już zapisanego sekretu. Po wykryciu transmisji bez HTTPS należy unieważnić lub zmienić klucz, sprawdzić zakres jego uprawnień oraz przeanalizować logi pod kątem użycia przez nieuprawnione podmioty.

Sprawdzenie konfiguracji na laptopie lub komputerze PC

Diagnostyka powinna objąć wszystkie miejsca, w których aplikacja buduje żądania API: konfigurację adresu usługi, kod klienta, biblioteki HTTP, zmienne środowiskowe oraz ustawienia serwera pośredniczącego. Należy sprawdzić, czy adres endpointu zaczyna się od https://, czy nie występuje wymuszone przejście na HTTP oraz czy klient nie akceptuje nieważnego certyfikatu przez wyłączenie jego weryfikacji. W narzędziach deweloperskich przeglądarki można przeanalizować zakładkę sieciową, a w aplikacji wykorzystującej własny klient HTTP trzeba sprawdzić rzeczywisty adres i nagłówki wysyłanego żądania.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy problemach z działaniem aplikacji na komputerze można rozpocząć od sprawdzenia połączenia sieciowego, ustawień systemu i objawów towarzyszących błędowi. Sama obecność HTTPS nie gwarantuje bezpieczeństwa całego rozwiązania: klucz musi być także odpowiednio przechowywany, ograniczony uprawnieniami, monitorowany i wymieniany po podejrzeniu ujawnienia.