Techniki bezpiecznego przeglądu kodu

Bezpieczny przegląd kodu pozwala identyfikować podatności w kodzie źródłowym przed wdrożeniem. W przeciwieństwie do funkcjonalnego przeglądu kodu koncentruje się na granicach zaufania, przepływach danych, niebezpiecznych interfejsach API, brakujących mechanizmach kontroli oraz błędach w logice bezpieczeństwa — a nie na poprawności lub stylu.

Automatyczne narzędzia SAST, takie jak Semgrep, SonarQube i CodeQL, szybko wykrywają znane wzorce, ale pomijają błędy logiki biznesowej, złożone podatności obejmujące wiele komponentów oraz problemy zależne od kontekstu. Przegląd ręczny wykrywa to, co pomija automatyzacja. Potrzebne są oba podejścia.

Przegląd bezpieczeństwa należy rozpocząć od zmapowania wszystkich punktów wejścia: punktów końcowych HTTP, obsługi komunikatów z kolejek, przesyłania plików, zadań zaplanowanych, webhooków oraz argumentów CLI. Każdy punkt wejścia przyjmujący dane zewnętrzne jest potencjalnym punktem wstrzyknięcia i wymaga dokładnego sprawdzenia.

Należy śledzić dane kontrolowane przez użytkownika od punktu wejścia przez aplikację aż do ich końcowego użycia. Czy trafiają do zapytania do bazy danych? Do polecenia powłoki? Do szablonu HTML? Do wywołania API? Należy prześledzić przepływ danych i sprawdzić każdy etap transformacji oraz sanityzacji.

Decyzje dotyczące bezpieczeństwa są podejmowane na granicach zaufania — w miejscach, w których dane przechodzą z mniej zaufanego kontekstu, takiego jak żądanie HTTP, do bardziej zaufanego, takiego jak baza danych lub system operacyjny. Każde przekroczenie granicy zaufania musi wiązać się z walidacją, sanityzacją lub autoryzacją danych.

Należy oznaczyć użycie: eval(), exec(), system(), shell_exec(), innerHTML, dangerouslySetInnerHTML, deserialize(), pickle.loads(), Runtime.exec(), ProcessBuilder, parserów XML, w których nie wyłączono rozwijania encji, oraz prymitywów kryptograficznych używanych bezpośrednio zamiast wysokopoziomowych interfejsów API.

Należy sprawdzić: Czy każdy wrażliwy endpoint jest chroniony uwierzytelnianiem? Czy autoryzacja jest sprawdzana po stronie serwera dla każdej operacji? Czy użytkownik może uzyskać dostęp do danych innego użytkownika przez zmianę parametru ID (IDOR)? Czy wrażliwe operacje są chronione przed CSRF?

Należy szukać bloków catch, które bezgłośnie ignorują wyjątki. Trzeba sprawdzić, czy komunikaty błędów wyświetlane użytkownikom nie ujawniają ścieżek wewnętrznych, stack trace’ów ani struktury bazy danych. Należy zweryfikować, czy wyjątki związane z bezpieczeństwem, takie jak AuthenticationException, są rejestrowane, a nie po cichu ignorowane.

Należy oznaczyć: użycie MD5 lub SHA-1 do haszowania haseł (należy używać bcrypt/Argon2), zakodowane na stałe klucze symetryczne lub IV, szyfrowanie w trybie ECB (należy użyć GCM lub CBC z HMAC), niestandardowe implementacje kryptograficzne oraz generatory liczb losowych, które nie są kryptograficznie bezpieczne.

Należy przejrzeć package.json/pom.xml pod kątem nieaktualnych zależności. Trzeba sprawdzić, czy w konfiguracji aplikacji tryb debugowania nie jest włączony na produkcji, czy strony błędów nie zawierają nadmiarowych informacji, czy poświadczenia administratora nie znajdują się w plikach konfiguracyjnych oraz czy nie brakuje nagłówków bezpieczeństwa (HSTS, CSP, X-Frame-Options).

Reguły Semgrep dopasowują wzorce składni z uwzględnieniem semantyki. Należy pisać niestandardowe reguły dla specyficznych wzorców bazy kodu. CodeQL traktuje kod jako dane — należy pisać zapytania do AST w celu znajdowania przepływów danych od źródeł do miejsc docelowych między plikami i wywołaniami funkcji.

Czym jest podatność IDOR i gdzie należy jej szukać podczas przeglądu kodu?

Skuteczny bezpieczny przegląd kodu łączy mapowanie punktów wejścia, śledzenie przepływu danych, analizę granic zaufania, wykrywanie niebezpiecznych interfejsów API oraz automatyczne narzędzia SAST. Wykrywa problemy bezpieczeństwa pomijane podczas przeglądu funkcjonalnego, szczególnie błędy logiki biznesowej i subtelne luki w autoryzacji.