Mindset testów bezpieczeństwa w codziennej pracy QA

Inżynierowie QA nie muszą stawać się specjalistami AppSec, aby wychwytywać typowe problemy bezpieczeństwa. Poznaj praktyczne zagrożenia bezpieczeństwa (XSS, błędy autoryzacji, IDOR, wycieki sekretów).

#testing #qa-automation #software-engineering

Wprowadzenie — bezpieczeństwo to zadanie każdego (ale nie wszyscy muszą być specjalistami)

Testowanie bezpieczeństwa często wydaje się odpowiedzialnością kogoś innego. Jest zespół AppSec lub pentester, który audytuje aplikację przed startem, albo jest obsługiwane przez narzędzia skanujące zintegrowane z CI.

Ale luki bezpieczeństwa to po prostu bugi — bugi z exploitowalnymi konsekwencjami. Jeśli inżynier QA może znaleźć null pointer exception, może znaleźć błąd autoryzacji. Jeśli może testować walidację inputu dla poprawności, może testować ją dla ataków injection.

Nie musisz stawać się specjalistą od bezpieczeństwa, aby zintegrować podstawowe myślenie o bezpieczeństwie z praktyką testową. Ten wpis obejmuje:

  • Praktyczne zagrożenia bezpieczeństwa, które QA może testować (XSS, autoryzacja, IDOR, exposure sekretów)
  • Lekką checklistę bezpieczeństwa dla codziennej pracy QA
  • Kiedy eskalować do specjalistów od bezpieczeństwa
  • Jak myśleć jak atakujący bez stawania się nim

To nie jest głębokie zanurzenie w kryptografię, threat modeling czy szczegóły OWASP Top 10. To praktyczny przewodnik po QA świadomym bezpieczeństwa.

Dlaczego QA powinien przejmować się bezpieczeństwem

Bugi bezpieczeństwa to bugi o wysokim wpływie

Bug funkcjonalny może powodować złe doświadczenie użytkownika. Bug bezpieczeństwa może powodować:

  • Wyciek danych — Dane użytkownika wyciekają do nieupoważnionych stron.
  • Przejęcie konta — Atakujący uzyskują dostęp do kont użytkowników.
  • Strata finansowa — Nieupoważnione transakcje, oszustwa.
  • Naruszenia zgodności — Kary GDPR, kary PCI-DSS, odpowiedzialność prawna.

Bugi bezpieczeństwa są nieproporcjonalnie drogie. Wychwycenie ich w QA jest znacznie tańsze niż naprawienie ich w produkcji.

QA ma unikalną perspektywę testową

Specjaliści od bezpieczeństwa skupiają się na lukach architektonicznych, słabościach kryptograficznych i bezpieczeństwie sieciowym. Inżynierowie QA skupiają się na funkcjach użytkownika i edge cases. Już testujesz:

  • Walidację inputu (czy możesz wprowadzić nieprawidłowe dane?)
  • Autoryzację (czy użytkownicy mogą uzyskać dostęp do tego, czego nie powinni?)
  • Obsługę błędów (czy błędy wyciekają wrażliwe informacje?)

Przy małej zmianie w mindset te testy funkcjonalne stają się testami bezpieczeństwa.

:::info[Testowanie bezpieczeństwa ≠ Testy penetracyjne] Testy penetracyjne to specjalistyczna aktywność, w której eksperci od bezpieczeństwa aktywnie atakują system, aby znaleźć luki. QA świadome bezpieczeństwa to integrowanie podstawowego myślenia o bezpieczeństwie w codzienne testowanie. Nie musisz być pentesterem, aby wychwytywać typowe problemy bezpieczeństwa. :::

Praktyczne zagrożenia bezpieczeństwa dla QA

1. Cross-Site Scripting (XSS)

Co to jest: Atakujący wstrzykuje złośliwy JavaScript na stronę internetową, który następnie jest wykonywany w przeglądarkach innych użytkowników.

Przykład: Pole komentarza pozwala użytkownikom wprowadzić <script>alert('XSS')</script>. Jeśli aplikacja renderuje to bez sanityzacji, skrypt uruchamia się w przeglądarce każdego użytkownika, który ogląda komentarz.

Rzeczywisty wpływ: Atakujący mogą kraść ciasteczka sesji, przekierowywać użytkowników na strony phishingowe lub modyfikować zawartość strony.

Jak testować:

  1. Znajdź pola inputowe (wyszukiwanie, komentarze, pola profilu, uploady plików z nazwami plików).
  2. Wprowadź typowe payloady XSS:
    • <script>alert('XSS')</script>
    • <img src=x onerror=alert('XSS')>
    • <svg onload=alert('XSS')>
  3. Wyślij i obejrzyj output. Jeśli przeglądarka wykonuje skrypt (pokazuje alert), znalazłeś XSS.

Oczekiwane zachowanie: Aplikacja powinna escapować lub sanityzować input. Powinieneś zobaczyć <script>alert('XSS')</script> wyrenderowane jako zwykły tekst, nie wykonany.

2. SQL Injection

Co to jest: Atakujący manipuluje zapytaniami SQL poprzez wstrzyknięcie złośliwego inputu, pozwalając im odczytać, modyfikować lub usuwać dane bazy danych.

Przykład: Formularz logowania z nazwą użytkownika i hasłem. Jeśli backend konstruuje zapytanie SQL jak:

SELECT * FROM users WHERE username = '$username' AND password = '$password'

Atakujący wprowadza admin' -- jako nazwę użytkownika. Zapytanie staje się:

SELECT * FROM users WHERE username = 'admin' -- ' AND password = ''

-- komentuje resztę zapytania. Atakujący loguje się jako admin bez znajomości hasła.

Jak testować:

  1. Znajdź pola inputowe, które wchodzą w interakcję z bazą danych (login, wyszukiwanie, filtry).
  2. Wprowadź payloady SQL injection:
    • ' OR '1'='1
    • admin' --
    • '; DROP TABLE users; --
  3. Obserwuj odpowiedź. Jeśli aplikacja zachowuje się nieoczekiwanie (loguje cię, zwraca wszystkie rekordy lub pokazuje błąd bazy danych), znalazłeś SQL injection.

Oczekiwane zachowanie: Aplikacja powinna używać parametryzowanych zapytań lub prepared statements. Złośliwy input powinien być traktowany jako dane, nie kod.

:::warning[Nie testuj na produkcji] Testy SQL injection mogą modyfikować lub usuwać dane. Testuj tylko na środowiskach deweloperskich lub stagingowych z testowymi danymi. :::

3. Błędy autoryzacji (Broken Access Control)

Co to jest: Użytkownicy mogą uzyskać dostęp do zasobów, których nie powinni (dane innych użytkowników, panele admina, ograniczone funkcje).

Przykład: Użytkownik ogląda swój profil pod /users/123. Zmienia URL na /users/124 i widzi profil innego użytkownika — w tym prywatne informacje.

Jak testować:

  1. Utwórz dwa konta testowe: zwykły użytkownik i admin (lub dwóch zwykłych użytkowników).
  2. Zaloguj się jako zwykły użytkownik. Zidentyfikuj zasoby powiązane z konkretnym użytkownikiem lub rolą (np. /orders/456, /admin/dashboard).
  3. Spróbuj uzyskać dostęp do zasobów, których nie powinieneś:
    • Zmień ID w URLach (/orders/457, /users/124)
    • Uzyskaj bezpośredni dostęp do endpointów admina (/admin/users)
    • Wyślij żądania API dla akcji, których nie powinieneś móc wykonać (np. DELETE /users/124 jako non-admin)

Oczekiwane zachowanie: Aplikacja powinna zwrócić 403 Forbidden lub 404 Not Found. Nieupoważnieni użytkownicy nigdy nie powinni widzieć ograniczonych danych ani wykonywać ograniczonych akcji.

4. Insecure Direct Object References (IDOR)

Co to jest: Specyficzny typ błędu autoryzacji, gdzie aplikacja ujawnia wewnętrzne identyfikatory (ID bazy danych, ścieżki plików) i nie waliduje, czy użytkownik jest upoważniony do ich dostępu.

Przykład: Pobierasz fakturę pod /api/invoices/1234. Zmieniasz URL na /api/invoices/1235 i pobierasz fakturę kogoś innego.

Jak testować:

  1. Zidentyfikuj endpointy, które odwołują się do obiektów przez ID (zamówienia, faktury, dokumenty, profile).
  2. Zanotuj własne ID obiektów.
  3. Zwiększ lub zmniejsz ID i spróbuj uzyskać do niego dostęp.
  4. Użyj innego konta testowego i spróbuj uzyskać dostęp do zasobów pierwszego konta.

Oczekiwane zachowanie: Aplikacja powinna zweryfikować, że uwierzytelniony użytkownik posiada lub jest upoważniony do dostępu do żądanego obiektu. Nieupoważnione żądania powinny zwrócić 403 lub 404.

5. Sekrety i exposure wrażliwych danych

Co to jest: Klucze API, hasła, tokeny lub PII (dane osobowe) są ujawniane tam, gdzie nie powinny być.

Typowe miejsca wycieków sekretów:

  • Kod po stronie klienta — Klucze API zakodowane na sztywno w JavaScript.
  • Komunikaty błędów — Stack traces, które zawierają dane uwierzytelniające bazy danych lub wewnętrzne ścieżki plików.
  • Logi — Logi aplikacji, które zawierają hasła, tokeny lub numery kart kredytowych.
  • Kontrola wersji — Pliki .env, config.json z danymi uwierzytelniającymi produkcji commitowane do Git.

Jak testować:

  1. Otwórz DevTools przeglądarki → zakładka Network. Inspekcja odpowiedzi API. Szukaj tokenów, kluczy lub PII, które nie powinny być wysyłane do klienta.
  2. Wywołaj błędy (wyślij nieprawidłowe dane, uzyskaj dostęp do ograniczonych endpointów). Sprawdź, czy komunikaty błędów ujawniają wrażliwe informacje (nazwy baz danych, ścieżki plików, stack traces).
  3. Przejrzyj kod źródłowy po stronie klienta (View Page Source). Szukaj apiKey, password, secret, token.

Oczekiwane zachowanie: Sekrety nigdy nie powinny być wysyłane do klienta. Komunikaty błędów powinny być ogólne (np. „Wystąpił błąd”) w produkcji, nie szczegółowe stack traces.

6. Wrażliwe dane w URLach (parametry zapytań)

Co to jest: Wrażliwe dane (hasła, tokeny, PII) przekazywane w URLach zamiast w body żądań.

Przykład: Link resetowania hasła: https://app.example.com/reset?token=abc123&email=user@example.com

Dlaczego to problem: URLe są logowane w historii przeglądarki, logach serwera i logach proxy. Każdy, kto ma dostęp do tych logów, może zobaczyć wrażliwe dane.

Jak testować:

  1. Inspekcja URLi podczas logowania, resetowania hasła, checkout lub jakiejkolwiek operacji obejmującej wrażliwe dane.
  2. Sprawdź, czy wrażliwe dane pojawiają się w parametrach zapytań.

Oczekiwane zachowanie: Wrażliwe dane powinny być wysyłane w nagłówkach żądań lub body POST, nie w parametrach zapytań URL.

Lekka checklista bezpieczeństwa dla QA

Użyj tej checklisty dla każdej funkcji, którą testujesz:

Walidacja inputu i injection

  • Czy mogę wstrzyknąć tagi <script> do pól inputowych? (XSS)
  • Czy mogę wstrzyknąć składnię SQL do pól formularza? (SQL injection)
  • Czy mogę wstrzyknąć komendy OS do nazw plików lub ścieżek? (Command injection)
  • Czy aplikacja waliduje długość, typ i format inputu?

Autoryzacja i kontrola dostępu

  • Czy mogę uzyskać dostęp do danych innego użytkownika poprzez zmianę ID w URLach lub żądaniach API? (IDOR)
  • Czy mogę wykonywać akcje admina jako zwykły użytkownik?
  • Czy mogę uzyskać dostęp do ograniczonych endpointów bez uwierzytelnienia?
  • Czy aplikacja wymusza autoryzację zarówno na frontendzie, jak i backendzie?

Exposure danych

  • Czy komunikaty błędów ujawniają stack traces, szczegóły bazy danych lub ścieżki plików?
  • Czy klucze API, tokeny lub sekrety są widoczne w kodzie po stronie klienta lub odpowiedziach API?
  • Czy hasła lub tokeny są wysyłane w parametrach zapytań URL?
  • Czy aplikacja loguje wrażliwe dane (hasła, karty kredytowe, PII)?

Uwierzytelnianie i zarządzanie sesją

  • Czy mogę zalogować się słabymi hasłami (password, 123456)?
  • Czy aplikacja wymusza wymagania dotyczące złożoności hasła?
  • Czy sesja wygasa po wylogowaniu lub nieaktywności?
  • Czy mogę ponownie użyć starych tokenów sesji po wylogowaniu?

HTTPS i bezpieczeństwo transportu

  • Czy aplikacja jest dostępna przez HTTP zamiast HTTPS?
  • Czy ciasteczka są oznaczone jako Secure i HttpOnly?
  • Czy aplikacja pozwala na mixed content (strona HTTPS ładująca zasoby HTTP)?

:::tip[Integruj sprawdzenia bezpieczeństwa do istniejących test cases] Nie potrzebujesz oddzielnych test cases bezpieczeństwa dla każdego scenariusza. Rozszerz swoje istniejące testy funkcjonalne o sprawdzenia bezpieczeństwa. Podczas testowania formularza logowania testuj również payloady SQL injection. Podczas testowania strony profilu testuj również autoryzację (czy użytkownik A może uzyskać dostęp do profilu użytkownika B?). :::

Kiedy eskalować do specjalistów od bezpieczeństwa

QA może wychwytywać typowe, high-impact bugi bezpieczeństwa. Ale niektóre problemy wymagają specjalistycznych umiejętności.

Eskaluj do AppSec lub pentesterów, gdy:

  • Potrzebujesz głębokiego threat modeling (np. analiza schematów szyfrowania, ocena protokołów uwierzytelniania).
  • Testujesz złożone wektory ataku (np. race conditions, timing attacks, zaawansowane SSRF).
  • Potrzebujesz certyfikacji zgodności (np. PCI-DSS, SOC 2, ISO 27001 wymaga audytów bezpieczeństwa stron trzecich).
  • Testujesz bezpieczeństwo infrastruktury (np. segmentacja sieci, reguły firewall, zasady IAM chmury).

Jako inżynier QA, twoim zadaniem jest wychwytywanie oczywistych luk i egzekwowanie podstawowej higieny bezpieczeństwa. Specjaliści zajmują się głębokimi, systemowymi lukami.

Narzędzia dla QA świadomego bezpieczeństwa

DevTools przeglądarki

Użyj zakładki Network do inspekcji żądań i odpowiedzi API. Szukaj:

  • Sekretów w odpowiedziach API
  • Wrażliwych danych w parametrach zapytań
  • Słabego zarządzania sesją (tokeny nie unieważnione po wylogowaniu)

OWASP ZAP (Zed Attack Proxy)

OWASP ZAP to darmowy skaner bezpieczeństwa, który działa jako proxy między twoją przeglądarką a aplikacją. Automatycznie wykrywa typowe luki (XSS, SQL injection, niezabezpieczone ciasteczka).

Jak używać:

  1. Zainstaluj ZAP.
  2. Skonfiguruj przeglądarkę do używania ZAP jako proxy (localhost:8080).
  3. Przeglądaj swoją aplikację normalnie.
  4. ZAP pasywnie skanuje pod kątem luk i raportuje znaleziska.

Burp Suite Community Edition

Burp Suite to kompleksowe narzędzie do testowania bezpieczeństwa. Community Edition jest darmowa i zawiera:

  • Proxy (przechwytywanie i modyfikowanie żądań HTTP)
  • Repeater (ponowne wysyłanie żądań z modyfikacjami)
  • Scanner (podstawowe skanowanie luk, płatna wersja ma więcej)

Skanery sekretów Git

Narzędzia takie jak truffleHog i gitleaks skanują repozytoria Git pod kątem przypadkowo commitowanych sekretów (klucze API, hasła, tokeny).

Uruchom je w CI, aby zapobiec dotarciu sekretów do produkcji:

docker run --rm -v $(pwd):/repo trufflesecurity/trufflehog:latest git file:///repo

Myślenie jak atakujący (bez stawania się nim)

Testowanie bezpieczeństwa wymaga zmiany mindset: zamiast pytać „czy to działa poprawnie?” pytaj „czy mogę to złamać w sposób, który szkodzi użytkownikom?”

Pytania do zadania

  • Czy mogę zobaczyć dane, których nie powinienem? Spróbuj uzyskać dostęp do zasobów innych użytkowników.
  • Czy mogę wykonać akcje, których nie powinienem? Spróbuj endpointów admina jako zwykły użytkownik.
  • Czy mogę ominąć walidację? Wyślij nieoczekiwany input (liczby ujemne, bardzo długie stringi, znaki specjalne).
  • Co się stanie, jeśli zmodyfikuję to żądanie? Zmień ID, zmień parametry, zmień nagłówki.
  • Jakie informacje ujawnia ten błąd? Wymuś błędy i inspekcja komunikatów.

Bezpieczne granice

  • Testuj tylko na środowiskach, do których jesteś upoważniony (development, staging, dedykowane środowiska testowe).
  • Nie testuj na produkcji, chyba że masz wyraźne upoważnienie i używasz testów tylko do odczytu.
  • Nie udostępniaj ani nie exploituj luk, które znajdziesz — zgłaszaj je odpowiedzialnie swojemu zespołowi lub kontaktowi bezpieczeństwa.

:::warning[Granice etyczne] Testowanie bezpieczeństwa może być prawnie wrażliwe. Zawsze testuj na systemach, do których jesteś upoważniony. Nigdy nie testuj na systemach stron trzecich bez wyraźnego pozwolenia. Nieupoważnione testowanie bezpieczeństwa jest nielegalne w większości jurysdykcji. :::

Przykład z prawdziwego świata: testowanie checkout e-commerce

Testujesz przepływ checkout. Oto jak zintegrować myślenie o bezpieczeństwie:

Test funkcjonalny

  1. Dodaj przedmiot do koszyka.
  2. Przejdź do checkout.
  3. Wprowadź dane płatności.
  4. Zakończ zamówienie.

Test wzbogacony o bezpieczeństwo

  1. Walidacja inputu: Spróbuj wprowadzić <script>alert('XSS')</script> w polu adresu wysyłki. Czy renderuje się jako tekst, czy wykonuje?
  2. Autoryzacja: Zakończ zamówienie i zanotuj ID zamówienia (/orders/1234). Spróbuj uzyskać dostęp do /orders/1235. Czy możesz zobaczyć czyjeś zamówienie?
  3. IDOR: Wyślij żądanie checkout przez Burp Suite lub DevTools przeglądarki. Zmień ID użytkownika w body żądania na ID innego użytkownika. Czy zamówienie zostanie utworzone dla niewłaściwego użytkownika?
  4. Exposure sekretów: Inspekcja odpowiedzi API checkout. Czy zawiera pełne numery kart kredytowych, CVV lub wewnętrzne ID użytkowników?
  5. HTTPS: Czy strona checkout jest serwowana przez HTTPS? Czy ciasteczka są oznaczone Secure i HttpOnly?

To zajmuje dodatkowe 5 minut i wychwytuje high-impact luki.

Podsumowanie

Testowanie bezpieczeństwa nie wymaga specjalizacji, aby zacząć. Jako codzienny inżynier QA możesz:

  • Testować typowe luki (XSS, SQL injection, błędy autoryzacji, IDOR).
  • Używać lekkiej checklisty bezpieczeństwa dla każdej funkcji.
  • Myśleć jak atakujący: „Czy mogę zobaczyć lub zrobić rzeczy, których nie powinienem?”
  • Używać darmowych narzędzi (OWASP ZAP, Burp Suite, DevTools przeglądarki) do wzmocnienia testów manualnych.

Nie musisz stawać się specjalistą AppSec, audytować implementacji kryptograficznych ani przeprowadzać testów penetracyjnych. Zostaw to specjalistom. Skup się na wychwytywaniu typowych, high-impact bugów bezpieczeństwa, zanim dotrą do produkcji.

Bezpieczeństwo to zadanie każdego. Zacznij od podstaw.

Zadanie na ten tydzień: Wybierz jedną funkcję, którą ostatnio testowałeś. Przejdź przez checklistę bezpieczeństwa z tego wpisu. Testuj XSS (spróbuj wstrzyknąć tagi <script>), testuj błędy autoryzacji (spróbuj uzyskać dostęp do zasobów innych użytkowników) i inspekcja odpowiedzi API pod kątem sekretów. Zgłoś wszelkie znaleziska swojemu zespołowi.