Pentest gRPC i Protobuf: autoryzacja i streaming

Pentest gRPC ocenia jednocześnie transport HTTP/2, konfigurację TLS lub mTLS, metadata, interceptory, serwisy i metody RPC, binarny format Protobuf, streaming oraz logikę autoryzacji obiektów. Sam brak REST endpointu i nieczytelne w przeglądarce body nie stanowią zabezpieczenia. Gdy tester pozyska pliki .proto, descriptor set albo dostęp do reflection, może analizować kontrakt równie precyzyjnie jak OpenAPI.

Najkrótsza odpowiedź: skuteczny pentest gRPC zaczyna się od inwentaryzacji serwisów, metod i typów streamu, następnie buduje macierz ról, tenantów, obiektów i pól. Każde RPC musi uwierzytelniać połączenie i autoryzować operację na backendzie; mTLS potwierdza klienta technicznego, ale nie zawsze użytkownika końcowego. Testy Protobuf powinny rozróżniać brak pola, wartość zero, nieznane pole i konflikt oneof, a testy streamingu obejmować limity, deadline, cancellation i backpressure. Dowody należy wykonywać na syntetycznych danych i przy uzgodnionej współbieżności.

gRPC jest popularny w mikroserwisach, systemach chmurowych, aplikacjach mobilnych, telemetrii i komunikacji service-to-service. Często bywa uznawany za „wewnętrzny”, mimo że jest osiągalny przez load balancer, service mesh, VPN, partnera albo gRPC-Web gateway. To właśnie różnice między polityką wewnętrzną, edge i transkodowanym REST bywają źródłem krytycznych luk.

Jak wygląda wywołanie gRPC na warstwach

Typowe gRPC działa na HTTP/2. Metoda jest identyfikowana ścieżką odpowiadającą serwisowi i RPC, metadata jest przenoszona w nagłówkach HTTP/2, wiadomości mają length-prefixed framing, a status końcowy i dodatkowe informacje trafiają do trailers. Dokumentacja gRPC Metadata opisuje metadata jako kanał key-value używany między innymi dla poświadczeń i trace context.

Model techniczny warto rozdzielić na sześć poziomów:

Poziom	Przykładowa kontrola	Typowy błąd
sieć i HTTP/2	port, ALPN, routing, maksymalny stream	interfejs „wewnętrzny” publicznie osiągalny
TLS/mTLS	certyfikat serwera i klienta	zaufanie dowolnemu certyfikatowi z szerokiego CA
metadata	token, tenant, trace, deadline	poświadczenia przesłane jawnie lub logowane
interceptor	authn, authz, rate limit	metoda omija interceptor przez inną rejestrację
Protobuf	typy, presence, oneof, repeated	domyślna wartość zmienia semantykę uprawnień
logika RPC	obiekt, funkcja, workflow	BOLA, BFLA lub nadużycie procesu biznesowego

API może oferować cztery wzorce: unary, server streaming, client streaming i bidirectional streaming. Każdy ma inny model zasobów i autoryzacji. Kontrola wykonana tylko przy otwarciu streamu może być nieaktualna przy dziesiątej wiadomości albo po zmianie roli.

Protobuf nie jest granicą bezpieczeństwa

Protocol Buffers Encoding Guide wyjaśnia, że format wire używa numerów pól, a nazwa i deklarowany typ wynikają dopiero ze schematu po stronie dekodującej. Kolejność serializacji nie jest gwarantowana. Parsery zachowują lub odrzucają nieznane pola zależnie od implementacji i sposobu konwersji.

Bezpieczeństwo zależy od semantyki, nie od binarności. Szczególnie ważne przypadki to:

field presence — pole nieobecne może różnić się od jawnego zera lub pustego tekstu;
unknown fields — starszy komponent może przechować pole, którego nie rozumie, a nowszy użyje go później;
oneof — ustawienie jednego pola usuwa inne, ale kolejność i translacja mogą tworzyć zaskakujący wynik;
repeated i map — liczba elementów i zduplikowane klucze wpływają na pamięć oraz logikę;
enum — nieznana wartość liczbowa może przejść między wersjami;
typy liczbowe — konwersja signed/unsigned i różne języki mogą inaczej obsłużyć zakres;
well-known types — Any, Struct, Timestamp i wrappers dodają dynamiczną semantykę;
schema evolution — ponowne użycie starego numeru pola może nadać historycznym danym nowe znaczenie.

Pola usunięte należy rezerwować w .proto, a walidację biznesową wykonywać po deserializacji. Sam compiler potwierdza zgodność typu, ale nie sprawdza, czy liczba jest dodatnia, identyfikator należy do tenanta albo przejście stanu jest dozwolone.

Reflection, health i odkrywanie powierzchni

gRPC Server Reflection umożliwia serwerowi opublikowanie usług i wszystkich typów używanych w requestach oraz responses. Narzędzia mogą dzięki temu działać bez lokalnych .proto. Reflection jest bardzo użyteczny w development i dla zatwierdzonych klientów, ale publiczna ekspozycja ułatwia inwentaryzację.

Wyłączenie reflection nie naprawia autoryzacji. Nazwy metod można pozyskać z klientów, logów, artefaktów build, mobilnej aplikacji, descriptor set albo gatewayu. Bezpieczeństwo przez ukrycie schematu spowalnia analizę, lecz nie jest kontrolą dostępu.

Standardowy gRPC Health Checking Protocol oferuje unary Check oraz streaming Watch. Informacja o nazwach i stanie usług może wspierać monitoring, ale publiczny endpoint nie powinien ujawniać wewnętrznej topologii. Reflection i health wymagają świadomej decyzji o ekspozycji, autoryzacji oraz rate limit.

Uwierzytelnianie: TLS, mTLS i call credentials

Oficjalny przewodnik gRPC Authentication rozróżnia channel credentials oraz call credentials. TLS uwierzytelnia serwer i chroni transport. mTLS dodatkowo identyfikuje klienta na poziomie certyfikatu. Token OAuth lub inny credential może być dołączony per call przez metadata.

Najważniejsze pytania projektowe to:

Czy certyfikat identyfikuje workload, organizację, urządzenie czy konkretnego użytkownika?
Jak mapowany jest SAN certyfikatu na principal i rolę?
Czy zaufany CA może wystawić certyfikat dla zbyt szerokiej grupy usług?
Czy token ma poprawnego issuer, audience, czas i scope?
Czy channel oraz call credentials są wymagane jednocześnie dla operacji wrażliwych?
Czy metadata z zewnętrznego klienta może nadpisać wartość ustawioną przez gateway?
Czy retry, redirect lub proxy nie wysyła credential do innego backendu?

Interceptors centralizują kontrolę, ale trzeba potwierdzić pokrycie każdej zarejestrowanej metody, reflection, health i ścieżek błędów. Jeden serwis dodany bez standardowego interceptora może ominąć cały model bezpieczeństwa.

Zakres bezpiecznego pentestu gRPC

Zakres powinien zawierać hosty, porty, protokoły, service mesh, gatewaye, środowiska, pliki .proto, descriptor sets, certyfikaty testowe, role i tenantry. Potrzebne są co najmniej dwa konta lub principals w osobnych tenantach oraz tożsamości każdej uprzywilejowanej roli.

Rules of engagement muszą określić limity:

równoczesnych kanałów i streamów;
wiadomości na stream i ich maksymalnego rozmiaru;
deadline oraz czasu utrzymania kanału;
dopuszczalnego testu retry i cancellation;
operacji wywołujących koszty, kolejki lub zewnętrzne efekty;
danych, które można odczytać lub zmienić.

Nie wykonuj testu wyczerpania HTTP/2 na produkcji w ramach standardowego pentestu. Wystarczy sprawdzić egzekwowanie uzgodnionego limitu. W szerszym kontekście wykorzystaj metodykę pentestu API REST, GraphQL i OAuth, rozszerzoną o streaming i Protobuf.

Techniczna metodyka pentestu gRPC

1. Inwentaryzacja endpointów i ścieżek routingu

Zbierz DNS, load balancery, ingress, service mesh, porty, ALPN, gRPC-Web i JSON transcoding. Porównaj reflection z repozytorium .proto, konfiguracją gatewayu i klientami. Zapisz serwis, metodę, typ RPC, ownera, wymagane role, klasyfikację danych i efekt biznesowy.

Sprawdź stare wersje pakietów, debug services, health, reflection i kanały administratora. Gateway może eksponować tylko część metod REST, podczas gdy natywny gRPC pozostaje osiągalny na tym samym load balancerze.

2. Transport i tożsamość kanału

Zweryfikuj TLS, nazwę certyfikatu, łańcuch zaufania, ALPN, protokoły i rotację. Dla mTLS sprawdź brak certyfikatu, certyfikat wygasły, niewłaściwy SAN, innego klienta testowego oraz unieważnienie. Nie próbuj kluczy spoza zakresu.

Porównaj bezpośrednie połączenie z trasą przez mesh i gateway. Upewnij się, że proxy usuwa metadata, którą tylko ono może ustanowić, oraz nie ufa nagłówkom tożsamości dostarczonym z Internetu.

3. Macierz authentication i metadata

Dla każdej metody wykonaj kontrolowane wywołania: bez credential, z credential wygasłym, z niewłaściwym audience, zakresem i tenantem, a następnie z prawidłowymi rolami. Sprawdź duplikaty kluczy metadata, wielkość nagłówków i różnice wielkości liter zgodnie z implementacją.

Sekrety nie powinny trafiać do komunikatów statusu, trailers, logów i trace. Zewnętrzna metadata korelacyjna musi być odróżniona od wartości wewnętrznej; klient nie powinien móc podszyć się pod trusted proxy.

4. Macierz metod, obiektów i pól

Zbuduj tabelę principal × metoda × obiekt × tenant × pole. Powtórz poprawny request konta A, zmieniając wyłącznie identyfikator na obiekt konta B. Następnie sprawdź funkcje uprzywilejowane oraz pola w requestach update/create. Backend musi egzekwować BOLA, BFLA i property-level authorization.

Protobuf może ukrywać mass assignment w polach, których klient UI nigdy nie ustawia. Jeżeli request przyjmuje cały obiekt domenowy, rola zwykła może próbować zmienić flagę administracyjną, ownera lub status. Używaj wyłącznie syntetycznych rekordów i odwracalnych zmian. Klasy ryzyka mapują się na OWASP API Security Top 10.

5. Schema-aware mutation

Zamiast losowych bajtów modyfikuj wiadomości świadomie na podstawie descriptoru. Sprawdź brak pola kontra wartość domyślna, granice liczb, nieznany enum, dodatkowe pole, duplikaty map key, oneof, zagnieżdżenie i rozmiar kolekcji. Celem jest wykrycie rozbieżności walidacji oraz wersji, nie awaria parsera.

Porównaj kilka komponentów: klient→gateway, gateway→backend i zapis→odczyt. JSON transcoding może utracić field presence, inaczej obsłużyć liczby 64-bitowe albo odrzucić unknown fields, podczas gdy natywny gRPC je zachowa. Ta sama operacja powinna mieć identyczną politykę niezależnie od transportu.

6. Streaming i zmiana kontekstu w czasie

Dla server streaming sprawdź, czy klient otrzymuje tylko dozwolone elementy i czy zmiana uprawnień zatrzymuje strumień. Dla client oraz bidirectional streaming potwierdź autoryzację każdej wiadomości, nie tylko otwarcia. Testuj zmianę tenanta, obiektu i typu komunikatu w środku strumienia.

Oceń kolejność, replay, half-close, przerwanie oraz ponowne połączenie. Po cancellation backend powinien zatrzymać kosztowną pracę i zwolnić zasoby. gRPC Deadlines Guide przypomina, że domyślnie deadline może nie być ustawiony, przez co klient potencjalnie czeka bez końca. Serwisy powinny definiować rozsądne deadlines i propagować je do downstream.

7. Limity i backpressure

W uzgodnionym środowisku sprawdź limit rozmiaru wiadomości, metadata, liczby streamów na kanał, wiadomości na sekundę, kolekcji w Protobuf i bufora wolnego konsumenta. Zwiększaj wartości stopniowo tylko do uzgodnionej granicy. Oczekiwany wynik to kontrolowany status, brak częściowej zmiany i szybkie zwolnienie pamięci.

Rate limit powinien rozumieć principal, tenant, metodę i koszt. Jedno RPC inicjujące drogie zapytanie lub długi stream nie jest równoważne lekkiej metodzie health. Limity wyłącznie per IP są niewystarczające za proxy i w środowisku partnerów.

8. Błędy, statusy i trailers

Sprawdź kody gRPC, grpc-message, szczegóły statusu, debug info i trailers. Klient nie powinien otrzymać stack trace, zapytania SQL, wewnętrznego hosta, nazw topiców ani pełnego obiektu w błędzie. Różnica NOT_FOUND kontra PERMISSION_DENIED może ujawniać istnienie cudzego zasobu — decyzja zależy od threat modelu.

Po błędzie transakcyjnym potwierdź brak częściowego zapisu i bezpieczny retry. Automatyczny retry metody nieidempotentnej może podwoić płatność lub zlecenie, nawet jeżeli sama autoryzacja jest poprawna.

Detekcja i obserwowalność gRPC

Log semantyczny powinien zawierać: pełną nazwę serwisu i metody, principal workloadu i użytkownika, tenant, wynik authn/authz, kod gRPC, czas, deadline, rozmiar wejścia/wyjścia, liczbę wiadomości i długość streamu. Nie loguj pełnej metadata ani binarnego requestu domyślnie.

Warto alarmować na:

publiczne użycie reflection lub health spoza zatwierdzonej sieci;
serie UNAUTHENTICATED i PERMISSION_DENIED na wielu metodach;
principal próbujący obiektów wielu tenantów;
nagły wzrost wiadomości, streamów lub czasu bez deadline;
wiele cancellation bez zatrzymania pracy downstream;
nieznane enumy, nadmiar unknown fields i błędy deserializacji;
metadata tożsamości nadesłaną spoza zaufanego proxy;
użycie starej wersji metody po terminie wycofania.

OpenTelemetry i proxy service mesh mogą dostarczać metryki, ale interceptory aplikacyjne znają wynik autoryzacji i koszt biznesowy. Potrzebna jest korelacja obu perspektyw.

Hardening gRPC i Protobuf

Używaj TLS wszędzie, a mTLS dla service-to-service zgodnie z modelem tożsamości.
Weryfikuj SAN i mapuj certyfikat na najmniejszy principal, nie tylko „zaufany CA”.
Wymagaj call credentials tam, gdzie trzeba rozpoznać użytkownika lub scope.
Centralizuj authn, authz, limity i logowanie w interceptorach oraz testuj pełne pokrycie.
Autoryzuj metodę, obiekt, tenant i każde modyfikowalne pole po stronie backendu.
Waliduj semantykę Protobuf po deserializacji; compiler nie zastępuje reguł biznesowych.
Rezerwuj numery i nazwy usuniętych pól, utrzymuj kompatybilność schematu w CI.
Ogranicz reflection i health do potrzebnych odbiorców, ale nie traktuj ukrycia jako authz.
Ustaw maksymalny rozmiar metadata, wiadomości, kolekcji, streamów i czasu.
Stosuj deadlines, propagację cancellation, backpressure i limity kosztu.
Ujednolić politykę natywnego gRPC, gRPC-Web i JSON transcoding.
Filtruj trusted metadata na granicy i nie przekazuj sekretów do logów lub errors.

Kontrole można powiązać z OWASP ASVS 5. Warstwy mesh, workload identity i prywatne load balancery powinien objąć pentest chmury AWS, Azure i GCP, a pełny proces oceny pozostaje częścią pentestu aplikacji webowej, jeśli gRPC obsługuje frontend lub aplikację mobilną.

Checklista gRPC przed produkcją

Źródła techniczne

Potrzebujesz ocenić gRPC w mikroserwisach? Warto połączyć schematy .proto, konta kilku ról, widoczność gatewayu i service mesh oraz kontrolowane testy streamingu. Raport powinien wskazać konkretną metodę, nieskuteczną granicę zaufania i test poprawki możliwy do automatyzacji.