Najczęstsze dziury bezpieczeństwa, które QA widzi, a nikt nie słucha

Najczęstsze dziury bezpieczeństwa, które QA widzi, a nikt nie słucha

W niemal każdej firmie technologicznej istnieje ten moment ciszy. QA zgłasza podatność bezpieczeństwa. W ticketach pojawia się słowo critical. Ktoś z zespołu dev rzuca okiem, ktoś inny wzdycha, Product dopisuje komentarz: nie teraz, mamy deadline. Ticket trafia do backlogu. Sprint mija. Potem kolejny. Aż któregoś dnia temat wraca, już nie jako ticket, tylko jako incydent, w którym nagle wszystko staje się pilne.

To nie jest problem braku wiedzy. Większość zespołów doskonale wie, czym jest XSS, SQL injection czy błędy kontroli dostępu. Problemem jest sposób podejmowania decyzji. Bezpiecznie nie znaczy technicznie poprawnie. Bezpiecznie znaczy odpornie na nadużycie.

OWASP od lat pokazuje, że najgroźniejsze ryzyka webowe nie są egzotyczne. Są powtarzalne i bolesne właśnie dlatego, że wyglądają jak drobiazgi. W 2021 na pierwszym miejscu OWASP Top 10 wskazuje Broken Access Control, czyli błędy kontroli dostępu. To numer jeden nie dlatego, że jest modny, tylko dlatego, że jest wszechobecny i ma ogromną skalę wystąpień w danych.

Ten artykuł nie jest listą straszaków. To mapa najczęstszych dziur bezpieczeństwa, które QA widzi regularnie, i które najczęściej są odkładane, bo nie wyglądają jak natychmiastowy pożar. A pożar przychodzi później.

Dlaczego QA widzi luki, których inni nie chcą widzieć?

QA myśli inaczej niż developer i Product. Developer myśli o tym, jak coś zbudować. Product o tym, co dowieźć i kiedy. QA myśli o tym, jak system może zostać użyty w sposób nieprzewidziany. QA z definicji nie ufa założeniom typu normalny użytkownik. Sprawdza, co się stanie, gdy ktoś zrobi coś głupiego, złośliwego albo po prostu przypadkowego. Dokładnie tak samo myśli atakujący.

Paradoks polega na tym, że im bardziej dojrzały technicznie zespół, tym łatwiej mu uwierzyć, że u nas to się nie zdarzy. Historia i dane pokazują, że zdarza się właśnie tam, gdzie system jest duży, złożony i rozwijany pod presją. Raport CERT Orange Polska podkreśla, że cyberzagrożenia rosną, a atakujący coraz lepiej wykorzystują nawyki i błędy konfiguracji, które dla zespołów są „banalne”.

Broken Access Control i IDOR: „przecież to tylko admin panel”

To jest najczęstsza klasa podatności w aplikacjach webowych i jednocześnie najbardziej zdradliwa, bo potrafi wyglądać jak zwykły błąd w logice, a nie jak zagrożenie. QA łapie ją zwykle w najbardziej banalny sposób. Loguje się jako zwykły użytkownik i próbuje wykonać akcję, która powinna być dostępna tylko dla administratora. Albo bierze URL z panelu admina, wkleja go do przeglądarki w sesji zwykłego użytkownika i widzi odpowiedź. Albo robi jeszcze prostszy trik: zmienia jedną cyfrę w identyfikatorze w URL-u czy w payloadzie i nagle dostaje fakturę, zamówienie, dokument albo dane profilu innego klienta.

I właśnie tu pojawia się klasyczne usprawiedliwienie: nikt nie zna tego URL-a, to tylko wewnętrzny panel, to działa tylko na localhost. Tyle że bezpieczeństwo nie polega na ukrywaniu ścieżek, tylko na kontroli uprawnień po stronie serwera. Jeśli backend ufa temu, co przychodzi z frontendu, to prędzej czy później ktoś to wykorzysta. W SaaSach ten błąd potrafi mieć najgorszy możliwy skutek: naruszenie poufności danych klientów. A wtedy nie mówimy już o bugfixie. Mówimy o incydencie, zgłoszeniu, audycie, potencjalnych karach, utracie kontraktów i reputacji.

Minimalny fix jest zwykle prosty: twarda kontrola uprawnień na każdym endpointzie, a nie tylko w UI. To oznacza autoryzację opartą o rolę i kontekst, sprawdzanie „ownershipu” zasobu i blokowanie wszelkich odwołań do obiektów, do których użytkownik nie ma prawa. Dodatkowo warto wprowadzić testy regresji na poziomie API, które wprost sprawdzają, że użytkownik A nie ma dostępu do zasobów użytkownika B. Ten test jest nudny, ale jest jedną z najlepszych polis ubezpieczeniowych, jakie może mieć produkt.

Injection: klasyk, który nigdy nie umiera

W teorii wszyscy wiemy, że injection to historia sprzed lat. W praktyce QA nadal znajduje miejsca, gdzie da się wstrzyknąć złośliwe dane, bo systemy są duże, endpointów jest dużo, a kod często powstaje w pośpiechu. Najczęstszy scenariusz wygląda tak: istnieje jeden „tymczasowy” endpoint, jeden import danych, jedno narzędzie admina, jedno legacy API, które nie dostało tej samej dbałości co główna ścieżka produktu.

QA znajduje to zwykle w bardzo prosty sposób. Próbuje wprowadzić dane, które wchodzą w kontekst interpretera: SQL, shell, parser wyrażeń, czasem nawet filtr wyszukiwania. I nagle okazuje się, że backend nie traktuje danych jako danych, tylko jako fragment polecenia. Wtedy pada standardowy argument obronny: przecież używamy ORM-a. Tylko że injection rzadko siedzi w miejscu, gdzie wszystko jest „ładnie” zrobione. Siedzi tam, gdzie ktoś zrobił szybkie obejście, ręczny query builder, dynamiczne sortowanie, albo przerzucił część logiki do parametrów.

Skutki potrafią być katastrofalne, bo injection jest często wejściem do większego łańcucha. Od wycieku danych, przez obejście uprawnień, po modyfikację krytycznych rekordów. I tu ważna rzecz: to nie jest ryzyko teoretyczne. To jest ryzyko, które atakujący umieją automatyzować.

Minimalny fix nie sprowadza się do „sanityzacji”. Działa podejście warstwowe: parametryzacja zapytań, unikanie dynamicznego składania komend, whitelisty dla sortowania i filtrowania, walidacja wejścia i przede wszystkim przegląd miejsc, które ominęły standard. Do tego testy bezpieczeństwa w CI, choćby podstawowe skany SAST i testy z gotowymi payloadami dla krytycznych endpointów. Najważniejsze jest jednak to, żeby injection nie było traktowane jako bug. To jest klasa ryzyka, która ma priorytet nad roadmapą.

XSS i CSP: „to tylko JavaScript”

XSS jest ignorowane wyjątkowo często, bo demonstracja wygląda jak żart. QA wkleja payload w komentarzu albo w nazwie pola, wyskakuje alert i ktoś mówi: no dobra, ale to tylko alert. Tyle że alert to tylko dowód, że da się wykonać kod w kontekście ofiary. W realnym ataku nie chodzi o alert. Chodzi o kradzież sesji, tokenów, dane z formularzy, a czasem o wykonanie akcji w imieniu użytkownika.

Najbardziej zdradliwe jest stored XSS, bo żyje w systemie. Ktoś zapisuje złośliwy payload, a potem otwiera go administrator, pracownik supportu albo użytkownik o wyższych uprawnieniach. I nagle „drobna luka” staje się wejściem do przejęcia konta, fraudu albo eskalacji uprawnień. W panelach wewnętrznych to jest szczególnie groźne, bo tam często jest najwięcej wrażliwych danych i najwięcej akcji o wysokiej wadze.

Zespół odkłada XSS, bo frontend sanitizuje dane. Tylko że frontend nie jest barierą bezpieczeństwa. Dane mogą wejść inną drogą: API, import, integracja, albo ktoś wyśle request bezpośrednio. Minimalny fix to sanitizacja i encoding po stronie serwera, plus sensowna polityka Content Security Policy, która ogranicza możliwość wykonywania nieautoryzowanego skryptu. QA może tu dodać bardzo praktyczny test regresji: wprowadzić kontrolowany payload i sprawdzić, czy zostanie zneutralizowany w każdym miejscu, gdzie dane są renderowane. To jest żmudne, ale jeśli raz to zrobisz dla krytycznych pól, obniżasz ryzyko całej klasy ataków.

Security misconfiguration: małe rzeczy, duże skutki

To jest kategoria, która wygląda na „czepianie się”, dopóki nie zrozumiesz, że to właśnie misconfiguration najczęściej ułatwia atak. QA bardzo często zgłasza rzeczy, które brzmią jak drobiazgi: CORS ustawiony zbyt szeroko, brak nagłówków bezpieczeństwa, włączony debug, publiczne source mapy, zbyt szczegółowe komunikaty błędów, brak limitów requestów, dostępne endpointy diagnostyczne.

Każdy z tych elementów osobno może wyglądać niegroźnie. Razem tworzą środowisko, w którym atak jest tańszy, szybszy i mniej ryzykowny dla atakującego. To też często jest „pierwszy krok” w łańcuchu. Nie musisz od razu mieć injection, żeby mieć incydent. Wystarczy, że ktoś dostanie zbyt dużo informacji z błędów, zobaczy strukturę aplikacji, endpointy, zależności, a potem użyje tego do dalszego ataku.

Dlaczego zespoły to ignorują? Bo „nie wpływa na funkcjonalność”. I tu jest sedno: bezpieczeństwo często nie wpływa na funkcjonalność do momentu, gdy wpływa najbardziej. Minimalny fix w misconfiguration jest zwykle najtańszy z całej listy. To reguły w bramkach CI, checklisty na infra, policy as code, standard nagłówków, prekonfigurowane szablony usług, skanowanie sekretów i baseline bezpieczeństwa dla każdej aplikacji. QA może tu zrobić coś bardzo praktycznego: dodać automatyczne testy nagłówków, CORS i podstawowych ustawień jako szybkie bramki. To nie musi być pentest. To ma być elementarna higiena.

Prawdziwy problem: nikt nie tłumaczy tego na język biznesu

Największym problemem nie jest to, że zespoły nie wiedzą, czym jest IDOR czy XSS. Problemem jest to, że QA mówi językiem podatności, a decydenci podejmują decyzje w języku ryzyka, pieniędzy i reputacji.

Jeśli QA mówi mamy broken access control, a Product słyszy to tylko edge case, decyzja będzie zła. Skuteczne zespoły QA nie tylko znajdują dziury. Potrafią je nazwać jako ryzyko biznesowe: wyciek danych klientów, fraud, downtime, koszty operacyjne i PR-owe. Dopiero wtedy ticket przestaje być „security bugiem”, a staje się decyzją, której nie opłaca się odkładać.

Co zmienia grę w praktyce

Po pierwsze, precyzyjne opisy ryzyka. Co może się stać, jak łatwo to wykorzystać, jaki jest impact. Bez straszenia, ale konkretnie.
Po drugie, prosta rekomendacja fixu. Nie elaborat, tylko minimalny krok, który obniża ryzyko.
Po trzecie, bramki. Jeżeli błąd klasy broken access control lub injection jest potwierdzony, to nie jest temat do backlogu. To jest temat do decyzji releaseowej.

Podumowanie

Dziury bezpieczeństwa nie są defektem technologicznym. Są defektem decyzyjnym. QA je widzi. Atakujący je widzą. Pytanie brzmi, czy organizacja potraktuje je poważnie zanim zrobi to ktoś z zewnątrz. Bo gdy zrobi to CERT, regulator albo media, jest już za późno.

W Quality Island pomagamy zespołom QA i IT zamykać luki bezpieczeństwa zanim staną się incydentami. Łączymy perspektywę QA, security i biznesu, żeby podatności przestały być edge case’ami, a zaczęły być realnym elementem decyzji.

Jeśli QA w Twojej firmie mówi o bezpieczeństwie, a nikt nie słucha, to nie jest problem QA. To sygnał, że potrzebujesz mechanizmu, który przekłada ryzyko techniczne na decyzję biznesową.