Bezpieczeństwo aplikacji kojarzy się najczęściej z technicznym aspektem. Jednak coraz większym wyzwaniem stają się zagrożenia związane z samym człowiekiem – użytkownikiem, administratorem czy nawet testerem. Ale jak to, człowiek celem ataku? Wszystko dlatego, że to właśnie człowiek jest najsłabszym ogniwem. W jaki sposób hakować człowieka? Wszystko dzięki tak zwanej inżynierii społecznej, która jest strategią stosowaną przez osoby lub grupy, aby manipulować ludźmi lub wprowadzać ich w błąd. Dzięki czemu udaje im się nakłonić ich do ujawnienia poufnych informacji lub wykonania działań, dzięki którym poziom bezpieczeństwa zostanie zmniejszony. Bazą do takich działań jest psychologia, a nie wiedza techniczna (ona oczywiście też jest potrzebna). Idealnym przykładem jest nieżyjący od 2 lat Kevin Mitnick. O nim samym wspominałem już w kilku moich artykułach o phishingu czy polityce bezpieczeństwa.
Musimy zrozumieć, że atakujący nie zawsze muszą łamać skomplikowane zabezpieczenia – często wystarczy, że skłonią potencjalną ofiarę do kliknięcia w link, podania hasła czy pobrania załącznika, który okaże się pułapką. Klasycznymi przykładami są phishing czy spear phishing. W kontekście aplikacji oznacza to, że nawet najlepiej zabezpieczony system może zostać złamany, jeśli użytkownik zostanie zmanipulowany do ujawnienia danych dostępowych. Biorąc pod uwagę wszechobecną pracę zdalną, takie akcje stają się coraz powszechniejsze. Dlatego też myślenie o bezpieczeństwie aplikacji nie może ograniczać się tylko do analizy kodu – musi obejmować także procesy, ludzi i sposób testowania.
Współczesne organizacje inwestują ogromne środki w testy penetracyjne, audyty kodu czy automatyczne skanery podatności. To bardzo dobrze, że od strony technicznej systemy są tak chronione. Niestety, coraz więcej atakujących zdaje sobie sprawę, że najsłabszym ogniwem wciąż pozostaje człowiek.
Według raportów branżowych, jak np. raport CERT z 2024 roku, (pozwolę sobie zacytować fragment): „Krajobraz zagrożeń występujących w polskiej cyberprzestrzeni ulega ewolucji. Z jednej strony obserwujemy dobrze znane z ostatnich lat kampanie phishingowe, których celem jest wyłudzenie loginów i haseł do popularnych usług e-mail lub serwisów społecznościowych, czy strony z fałszywymi ogłoszeniami imitujące serwisy, takie jak OLX bądź Allegro. Z drugiej strony pojawiają się nowe, interesujące z punktu widzenia cyberbezpieczeństwa kampanie”.
Niezależnie, jak na to spojrzymy, musimy uświadomić sobie, że większość udanych cyberataków zaczyna się od manipulacji użytkownikiem. Zdając sobie sprawę, że zagrożenia socjotechniczne są dziś równie groźne co błędy w kodzie, zrozumiemy, że wszelkie firewalle, szyfrowania czy mechanizmy autoryzacji tracą na znaczeniu.
No dobrze, wiemy już, czym jest socjotechnika i dlaczego jest tak groźna. Skupmy się zatem na grupie, która jest tak bliska memu sercu, czyli testerom oprogramowania. Możecie zapytać, dlaczego właśnie im. Nie lepiej atakować kogoś na wyższym stanowisku, jak administrator czy prezes? Otóż nie do końca. Testerzy to niestety często marginalizowana i niedoceniana grupa. Co więcej, w dojrzałych organizacjach traktuje się ich po macoszemu, oszczędzając na szkoleniach. Jeśli przyjrzymy się uważnie, kim jest tester oprogramowania, zauważymy, że często posiada on kluczowe uprawnienia i pracuje na danych, które mogą być bardzo cenne z punktu widzenia atakującego. Ale rozbijmy to na czynniki pierwsze, aby łatwiej zrozumieć, dlaczego byliśmy w błędzie.
-
Dostęp do środowisk
Testerzy korzystają ze środowisk testowych, stagingowych, a bywa, że nawet produkcyjnych. Mają dostęp do:
systemów CI/CD,
serwerów aplikacyjnych,
baz danych testowych,
API z obniżonym poziomem zabezpieczeń.
Tylko w tym aspekcie atakujący może uzyskać dane do logowania lub wykorzystać środowisko testowe jako furtkę do infrastruktury produkcyjnej, szczególnie gdy separacja środowisk nie jest pełna. -
Dostęp do kont testowych
Konta testowe często mają uprzywilejowane role (np. „admin” umożliwiający weryfikację wszystkich funkcjonalności). Hasła do tych kont bywają współdzielone w zespole, trzymane w plikach tekstowych czy arkuszach.
-
Dostęp do danych
W wielu organizacjach w testach używa się realnych danych produkcyjnych (np. fragmentów baz klientów, danych finansowych, danych medycznych). Nawet jeśli są częściowo zanonimizowane, to i tak mogą zawierać wartościowe informacje (np. adresy e-mail). To sprawia, że testerzy dysponują danymi wrażliwymi, a ich stacje robocze i konta stają się atrakcyjnym celem phishingu czy malware’u.
Teraz wiemy już, dlaczego testerzy są cennym „obiektem” potencjalnego ataku. Niestety, to nie koniec problemu. W praktyce często na testach i testerach oszczędzamy, a to prowadzi nas do kilku problemów:
Zazwyczaj (choć nie zawsze) główne szkolenia z bezpieczeństwa kierowane są do deweloperów i administratorów – testerzy bywają pomijani.
Część organizacji nie przykłada wagi do ochrony środowisk testowych, traktując je jako „mniej istotne”.
- Wyłudzenie danych uwierzytelniających – przejęcie kont testowych, a w konsekwencji dostęp do systemów stagingowych i CI/CD.
- Eksfiltracja danych testowych – możliwość pozyskania danych osobowych lub biznesowych.
- Atak lateralny – wykorzystanie środowiska testowego do przedostania się do sieci wewnętrznej i na produkcję.
- Sabotaż procesu QA – manipulowanie danymi testowymi i wynikami testów, co może skutkować przepuszczeniem luk bezpieczeństwa do produkcji.
Całość brzmi jak poważny problem. Na szczęście jest kilka podstawowych praktyk po stronie testerów i managementu, które mogą nas uratować:
- Selektywne dane testowe – używajcie generatorów danych, a nie realnych baz produkcyjnych.
- Separacja środowisk – brak połączenia sieciowego z produkcją, osobne konta i role.
- Bezpieczne przechowywanie haseł – menedżer haseł zamiast plików .txt czy arkuszy; nieużywanie jednego hasła do wielu systemów.
- Okresowe szkolenia z bezpieczeństwa – phishing, bezpieczne korzystanie z narzędzi, higiena kont.
- Monitorowanie aktywności – logi dostępu do środowisk i danych testowych powinny być analizowane tak samo, jak produkcyjne.
Słusznym rozwiązaniem byłoby wykorzystanie zespołu testerów w większym zakresie. Tradycyjne, podstawowe i najczęściej spotykane zadania testerów skupiają się na testach funkcjonalnych, wydajnościowych czy użyteczności. A gdyby tak wykorzystać ich umiejętności szerzej, aby:
- uwzględniać scenariusze ataków socjotechnicznych – np. sprawdzać, czy aplikacja odpowiednio reaguje na podejrzane próby logowania lub czy ostrzega użytkownika przed podejrzanym linkiem,
- edukować zespół projektowy i biznesowy – wskazywać miejsca, w których użytkownik może zostać zmanipulowany (np. przy braku jasnych komunikatów o błędach, słabej walidacji danych czy mylących interfejsach),
- współpracować z działem bezpieczeństwa – łączyć wiedzę o jakości oprogramowania z perspektywą security, aby wykrywać nie tylko błędy techniczne, ale i ryzyka związane z użytkowaniem aplikacji,
- promować „security by design” – czyli podejście, w którym bezpieczeństwo i odporność na manipulację są brane pod uwagę od pierwszych etapów projektu, a nie dopiero po wdrożeniu.
Dzięki temu zespoły zapewnienia jakości stałyby się kluczowym ogniwem w ochronie organizacji przed atakami, które nie bazują wyłącznie na technologii, ale na ludzkiej podatności. Okresowe szkolenia są w moim mniemaniu bardzo istotne z prostego powodu: bezpieczeństwo to nie jest coś, co zapewnia się raz.
Bezpieczeństwo to ciągły proces, który nigdy nie powinien się zakończyć.
- Senior software tester
-
Tester związany z branżą od prawie 5 lat, w tym czasie realizował projekty w sektorze e-commerce. Zawsze chętny na kolejne projekty, bo łączy pracę z pasją. Entuzjasta security, który prywatnie zajmuje się rekonstrukcją historyczną wikingów i łucznictwem tradycyjnym.
