Podczas audytu bezpieczeństwa integracji (plugin + API) wykryliśmy ryzyko związane z OAuth: integracja prosiła o zbyt szerokie scope’y, a tokeny dostępu były przechowywane w sposób umożliwiający eskalację skutków incydentu (np. po przejęciu konta w panelu lub błędzie w logowaniu). Naprawa: minimalizacja uprawnień (least privilege), krótkie TTL tokenów, bezpieczne przechowywanie (encrypt-at-rest), rotacja i revocation, oraz testy scenariuszy “token theft”.
Kontekst: integracje to nowe perimeter
Klient to organizacja SaaS, która mocno rośnie i ma ekosystem integracji: wtyczka do popularnej platformy (CRM / helpdesk / e-commerce), webhooki, synchronizacje kontaktów, importy danych i automatyzacje.
Z biznesowego punktu widzenia integracje są złotem: mniej ręcznej pracy, więcej retention. Z punktu widzenia bezpieczeństwa to często “drzwi serwisowe”, które ktoś kiedyś zrobił szybko, a potem nikt nie chce dotykać, bo “działa”.
Audyt miał odpowiedzieć na pytanie: czy nasza integracja ma dokładnie taki dostęp, jaki potrzebuje, czy “na zapas”?
Problem: OAuth bez zasady least privilege
OAuth sam w sobie jest OK. Problem zaczyna się, gdy:
- integracja prosi o scope’y szersze niż realnie potrzebne,
- tokeny żyją długo i działają szeroko,
- nie ma sensownej rotacji, revocation i monitoringu,
- przechowywanie tokenów nie jest zaprojektowane jak dla kluczy do sejfu.
W badanej integracji znaleźliśmy kombinację: zbyt szerokie scope’y + tokeny o długim życiu + brak konsekwentnej polityki ograniczeń.
W skrócie: nawet jeśli prawdopodobieństwo kradzieży tokena jest niskie, to impact był zbyt wysoki.
Jak pracowaliśmy: audyt OAuth “po dorosłemu”
Audyt zrobiliśmy w trzech warstwach, bo OAuth to nie tylko “przycisk Zaloguj przez X”.
- Consent i scope’y: co integracja żąda, co dostaje, co naprawdę wykorzystuje.
- Token lifecycle: TTL, refresh, rotacja, unieważnianie, zachowanie po zmianie hasła / usunięciu integracji.
- Storage i ekspozycja: gdzie token trafia, czy jest logowany, czy jest szyfrowany, czy jest dostępny dla zbyt wielu komponentów.
Dodatkowo przetestowaliśmy scenariusze nadużyć: “co jeśli token wycieknie” i “co jeśli ktoś przejmie konto admina w panelu integracji”.
Odkrycie: nadmiarowe scope’y i zbyt duży blast radius
W modelu multi-tenant integracja zwykle powinna działać “w obrębie” konkretnego konta lub organizacji. W praktyce scope’y mogą dawać dostęp do:
- pełnych list kontaktów,
- danych użytkowników,
- ticketów, historii, notatek,
- eksportów i operacji masowych.
W tym przypadku scope’y były szersze niż potrzebne do podstawowej funkcji integracji (synchronizacja jednego typu obiektu). Co gorsza, integracja nie miała wyraźnego rozdziału uprawnień pomiędzy operacje odczytu i zapisu, a tokeny nie były ograniczane do minimalnego zestawu endpointów.
To tworzyło niebezpieczny wzorzec: “jeden token i możesz dużo”.
Ryzyko biznesowe: gdy token jest kluczem master-key
Tu nie ma filozofii. W scenariuszu kompromitacji tokena (np. przez przejęcie konta integracji, leak w logach, błąd w panelu admina, słabe zabezpieczenie backupów) skutki mogły obejmować:
- masowy odczyt danych (łatwy exfil),
- modyfikacje w zintegrowanym systemie (np. tworzenie/edycja rekordów),
- nadużycia w automatyzacjach (triggerowanie działań),
- naruszenie zaufania klientów (bo integracja działa “w ich imieniu”).
W SaaS najgorsze jest to, że incydent integracji potrafi dotknąć wielu klientów naraz. Nie dlatego, że ktoś “hacknął bazę”, tylko dlatego, że integracja ma dostęp większy niż powinna.
Remediacja: co zmieniliśmy, żeby uprawnienia były proporcjonalne do funkcji
Naprawa była oparta o zasadę: scope to umowa. Jeśli prosisz o więcej, niż potrzebujesz, to wcześniej czy później płacisz za to odsetkami.
1) Minimalizacja scope’ów (least privilege)
Przeprojektowaliśmy zakresy uprawnień tak, żeby integracja mogła robić tylko to, co realnie musi. Rozdzieliliśmy uprawnienia na profile (np. read-only vs read-write) i powiązaliśmy je z faktycznymi funkcjami.
2) Ograniczenie tokenów w czasie i w zasięgu
Krótsze TTL access tokenów, kontrolowane refresh tokeny, ograniczenie “życia” integracji bez aktywności. Tam gdzie możliwe, wprowadziliśmy dodatkowe ograniczenia kontekstowe (np. powiązanie tokena z konkretną organizacją/tenantem).
3) Bezpieczne przechowywanie tokenów
Tokeny zostały objęte szyfrowaniem w spoczynku (encrypt-at-rest), a dostęp do nich został ograniczony do minimalnego zestawu usług. Dodatkowo wykluczyliśmy ryzyko logowania tokenów w debug/trace.
4) Rotacja i revocation jako standard
Dodaliśmy mechanizmy unieważniania tokenów po odłączeniu integracji, zmianie krytycznych ustawień lub podejrzeniu incydentu. Rotacja nie jest “miłym dodatkiem”, tylko częścią higieny.
5) Testy regresji na scenariusze “token theft”
Wprowadziliśmy testy i checklistę, które sprawdzają m.in.: czy token da się użyć po revocation, czy scope’y są minimalne, czy endpointy nie honorują operacji poza zakresem.
Po wdrożeniu wykonaliśmy retesty i potwierdziliśmy, że integracja działa na minimalnych uprawnieniach, a kompromitacja pojedynczego tokena ma ograniczony zasięg.
Efekt: mniejsze ryzyko incydentu “hurtowego” i lepsza kontrola nad integracjami
Największy efekt biznesowy był taki, że integracje przestały być “czarną skrzynką” z szerokim dostępem. Klient dostał:
- czytelne profile uprawnień,
- krótszy czas życia kluczy,
- realną możliwość szybkiego odcięcia dostępu,
- i wzorzec do wdrażania kolejnych integracji.
To jest ten typ zmiany, który nie krzyczy w UI, ale dramatycznie obniża ryzyko.
Jak Pentestica może pomóc
Jeśli masz integracje oparte o OAuth, webhooki, tokeny API, automatyzacje albo marketplace wtyczek, audyt powinien obejmować nie tylko “czy logowanie działa”, ale też:
- scope’y i zasadę least privilege,
- przechowywanie i lifecycle tokenów,
- revocation, rotację i monitoring,
- scenariusze nadużyć (bo to one robią incydenty).
W Pentestica robimy audyty bezpieczeństwa aplikacji i integracji w sposób, który daje konkret: co ograniczyć, gdzie, jak i jak to później testować.
Redakcja Pentestica.pl zespół ekspertów ds. cyberbezpieczeństwa, którzy dzielą się swoją wiedzą i praktycznym doświadczeniem w zakresie testów penetracyjnych, audytów it, regulacji NIS2, MiCA, DORA i nowych technologii. Nasi autorzy to doświadczeni pentesterzy, specjaliści bezpieczeństwa IT oraz konsultanci, którzy z pasją tworzą profesjonalne artykuły, aby przybliżyć Państwu tematykę cyberbezpieczeństwa w praktyce. Znajdą tu Państwo dogłębne analizy zagrożeń, omówienia technik ataków, porady dotyczące ochrony systemów oraz praktyczne wskazówki z zakresu testów penetracyjnych i wdrożeń regulacji. Naszym celem jest dostarczanie rzetelnej i aktualnej wiedzy, która pomoże Państwu lepiej zrozumieć świat cyberbezpieczeństwa i skutecznie chronić swoje zasoby cyfrowe.