Audyt bezpieczeństwa aplikacji: 12 rzeczy, które sprawdzamy przed wdrożeniem

Większość luk w aplikacjach jest przyziemna: zbyt szerokie uprawnienia, stare biblioteki, hasło ustawione raz i zapomniane. Audyt bezpieczeństwa aplikacji sprawdza je po kolei, zanim zrobi to ktoś z zewnątrz. Poniżej pokazujemy, jak wygląda nasz audyt przed wdrożeniem, co obejmuje i co trafia do Twoich rąk.

Od czego zaczyna się audyt

Audyt zaczyna się od ustaleń, nie od skanera. W pierwszym dniu spisujemy trzy rzeczy: zakres, zasady testów i model zagrożeń.

Zakres to lista domen, interfejsów API, aplikacji mobilnych i środowiska testowego, wraz z kontami testowymi dla każdej roli użytkownika. Testujemy staging. Produkcji z danymi Twoich klientów nie dotykamy.

Zasady testów ma podpisać klient. Pisemna zgoda określa okno czasowe, to, co wolno, i kontakt awaryjny. Ataków przeciążeniowych w zasadach nie ma, a socjotechnika wymaga Twojej osobnej zgody.

Model zagrożeń mieści się na jednej stronie: jakie dane są najcenniejsze, kto mógłby je chcieć i gdzie w systemie leżą pieniądze. Dzięki niemu wiemy, na czym spędzić więcej czasu.

Dlaczego kolejność ma znaczenie

Lista idzie od rzeczy najtańszych do najdroższych w sprawdzeniu. Automaty kosztują godziny i od razu odsiewają oczywiste problemy. Testy manualne kosztują dni, więc zaczynamy je, gdy wiemy, co już naprawiono. Konfigurację sprawdzamy na końcu, bo wymaga rozmowy z ludźmi, którzy mają dostęp do systemów.

Taka kolejność oszczędza też Twój budżet. Nie płacisz za ręczne szukanie luki, którą znajdzie skaner zależności w kilka minut.

Pięć etapów w pięć dni roboczych

Dla typowej aplikacji B2B audyt trwa od 4 do 5 dni roboczych. Przebieg jest zawsze taki sam: zakres i zgoda, testy automatyczne, testy manualne, konfiguracja i operacje, raport z retestem.

Pięć etapów audytu typowej aplikacji B2B. Najwięcej czasu zajmują testy manualne.

Standardem, do którego porównujemy aplikację, jest OWASP ASVS poziom 2. Dla fintechu i medycyny celujemy w poziom 3. Pentesty wykonujemy sami, więc nie czekasz na zewnętrznego partnera ani na jego kalendarz.

Dzień 0 i 1: zakres, zgoda i automaty

Pierwsze pięć punktów z naszej listy to zakres i testy automatyczne. Automaty dają kandydatów do sprawdzenia. Każdy wpis potwierdzamy ręcznie, żeby w raporcie nie było fałszywych alarmów.

1. Zakres, zgoda i model zagrożeń. Wszystko, co opisaliśmy wyżej, zanim ruszy pierwsze narzędzie.
2. Zależności i obrazy. osv-scanner lub pnpm audit dla bibliotek, trivy dla obrazów Docker. Stara biblioteka ze znaną luką to klasyczne znalezisko, a poprawka bywa tak prosta jak podniesienie wersji.
3. Sekrety w historii repozytorium. gitleaks przeszukuje całą historię repozytorium, łącznie ze starymi wersjami. Klucz usunięty rok temu nadal działa, jeśli go nie wymieniono.
4. Analiza statyczna kodu. semgrep z regułami OWASP dla Twojego stacku wyłapuje wzorce, które zwykle kończą się luką.
5. Skan działającej aplikacji. OWASP ZAP lub Burp na stagingu, nuclei na infrastrukturze oraz testssl.sh i Mozilla Observatory dla TLS, nagłówków i CSP.

Dni 2 do 4: testy manualne według OWASP ASVS L2

Tu spędzamy najwięcej czasu, bo narzędzie nie rozumie Twojego biznesu. Skaner nie wie, że faktura jednej firmy nie powinna być widoczna dla drugiej. My to sprawdzamy.

6. Autoryzacja i izolacja danych. Czy użytkownik zmieniający numer w adresie widzi cudze rekordy (IDOR)? Czy rola „pracownik” może wykonać akcję „administrator”? W systemach wielofirmowych sprawdzamy, czy dane jednej firmy są odgrodzone od drugiej.
7. Uwierzytelnianie i sesje. Reset hasła, ochrona przed zgadywaniem haseł i limity prób, czas życia sesji, wylogowanie, 2FA, tokeny w adresach URL.
8. Walidacja wejścia. SQL injection, XSS, SSRF, wgrywanie plików oraz wstrzyknięcia w integracjach: webhookach i importach CSV.
9. Logika biznesowa. Pominięcie kroku płatności, podwójne użycie kuponu, wyścig dwóch żądań na tym samym saldzie. Te błędy wyglądają jak poprawny ruch, dlatego znajduje je tylko człowiek.
10. API i aplikacje mobilne. Brak limitów, pola w odpowiedziach, których klient nie potrzebuje, mass assignment i endpointy bez dokumentacji. W aplikacjach iOS i Android, według OWASP MASVS, sprawdzamy dane w keychain i keystore, certificate pinning, sekrety w pliku instalacyjnym, deep linki i logi.

Dzień 4: konfiguracja i operacje

Dobrze napisany kod nie ochroni systemu, jeśli klucz do produkcji leży w czacie, a kopia zapasowa nigdy nie została odtworzona. Ten etap dotyczy ludzi i konfiguracji.

11. Sekrety, uprawnienia i kopie. Gdzie leżą sekrety, jak są rotowane, kto ma dostęp do produkcji i czy na chmurze, DNS, w sklepach z aplikacjami i w repozytorium włączono MFA. Uprawnienia IAM mają być najmniejsze konieczne, a CI dostaje osobne role. Kopie muszą istnieć, być szyfrowane, a ich odtworzenie przetestowane i zmierzone w czasie.
12. Monitoring, logi i RODO. Czy system zauważy tysiąc nieudanych logowań. Czy logi nie zawierają danych osobowych. Czy istnieje rejestr przetwarzania, umowy powierzenia z dostawcami (hosting, e-mail, analityka) i zasady retencji.

Co dostajesz w raporcie

Raport powstaje w dniu 5 i ma dwie warstwy: jedną dla zarządu, drugą dla zespołu technicznego.

Streszczenie dla zarządu mieści się w trzech zdaniach. Zawiera ocenę ogólną i liczbę znalezisk w podziale na poziomy ważności. Dalej każde znalezisko ma ten sam układ.

Raport ma streszczenie dla zarządu i kartę każdego znaleziska.

• opis problemu i dowód, że da się go odtworzyć,
• wpływ biznesowy zapisany językiem, który zrozumie nietechniczna osoba,
• ocena CVSS 3.1,
• naprawa krok po kroku,
• właściciel poprawki i termin.

Raport zawiera też listę rzeczy sprawdzonych bez zastrzeżeń. Wiesz więc, co jest do naprawy i co przeszło test. Retest po poprawkach jest w cenie. Trafia do tego samego raportu z adnotacją „naprawione” lub „otwarte”.

Gdzie audyt wpisuje się w proces

Audyt nie jest osobną usługą doklejoną na końcu. To część etapu „Wdrożenie” w naszym procesie sześciu etapów: Pomysł, Onboarding, Projektowanie, Produkt, Wdrożenie, Rozwój i utrzymanie.

Audyt przed startem to część etapu Wdrożenie. Wcześniej wchodzą testy i przegląd kodu, później cotygodniowy skan zależności.

Zasada jest jedna: krytyczne i wysokie znaleziska naprawiamy przed startem. Produkt nie wychodzi z otwartym krytycznym błędem. Raport dostajesz razem z produktem, a kod, projekty i konta należą do Ciebie od pierwszego dnia, więc możesz pokazać go audytorowi, inwestorowi lub klientowi korporacyjnemu.

Po wdrożeniu bezpieczeństwo wchodzi w utrzymanie: skan zależności co tydzień w CI, przegląd uprawnień co kwartał, retest po każdej dużej funkcji i pełny audyt raz w roku.

Co zrobić dziś

Weź godzinę i sprawdź punkt 11 z listy, bo jest najtańszy. Spisz, kto ma dostęp do produkcji, chmury, DNS, sklepów z aplikacjami i repozytorium. Przy każdej osobie zaznacz, czy ma włączone MFA. Jeśli lista jest dłuższa, niż się spodziewałeś, masz pierwsze znalezisko bez żadnego skanera.

Drugi krok na dziś: zapytaj zespół, kiedy ostatnio odtworzono kopię zapasową w teście. Brak odpowiedzi jest odpowiedzią.

Porozmawiajmy o audycie

Planujesz start aplikacji albo masz ją od dawna i nikt nie sprawdzał jej z zewnątrz? Opowiedz nam, co masz. W bezpłatnej rozmowie ustalimy zakres i to, czego brakuje, żeby audyt miał sens. Umów bezpłatną rozmowę.

Jeśli szukasz wykonawcy, który robi audyt przed startem w standardzie, przeczytaj też jak wybrać software house. Gdy przejmujesz aplikację po kimś innym, zacznij od tekstu Przejęcie istniejącej aplikacji. Koszt audytu i innych elementów projektu omawiamy w artykule Ile kosztuje aplikacja.