Przejdź do głównej zawartości

Mishandling of Exceptional Conditions: Metody testowania

Metody testowania podatności: Mishandling of Exceptional Conditions​

Punktem wyjścia jest test WSTG-ERRH-01 Testing for Improper Error Handling z OWASP Web Security Testing Guide 4.2. WSTG skupia się na tym, co błędy ujawniają. Wymienia też skutki takie jak DoS i ominięcie kontroli, ale nie podaje dla nich procedury testu — punkty 4–7 ją uzupełniają.

1. Błędy serwera WWW​

Według WSTG, żeby wywołać komunikaty błędów serwera:

  • żądaj nieistniejących plików i katalogów (404),
  • żądaj istniejących katalogów (403, pusta strona albo listing katalogu),
  • wyślij żądanie łamiące specyfikację HTTP — bardzo długa ścieżka, uszkodzony format nagłówków, zmieniona wersja HTTP.

Nawet gdy aplikacja ma własne strony błędów, żądanie niezgodne z RFC obsługuje wbudowany serwer — a jego domyślnych komunikatów często nikt nie nadpisał.

2. Błędy aplikacji​

Procedura z WSTG:

  1. Zidentyfikuj punkty wejścia, w których aplikacja oczekuje danych.
  2. Ustal oczekiwany typ danych (string, liczba, JSON, XML…).
  3. Fuzzuj każdy punkt wejścia pod kątem tego typu.
  4. Na podstawie odpowiedzi ustal, która usługa zwraca błąd (baza, mikroserwis…), i zawęź listę danych testowych.

Jeśli na pełny fuzzing nie ma czasu, WSTG radzi dobrać ręcznie dane, które najłatwiej psują parser: zamykający nawias w ciele JSON, długi tekst tam, gdzie oczekiwane są dwa znaki, CRLF w parametrach, znaki niedozwolone w nazwach plików.

Uwaga na format odpowiedzi. Błąd bywa zwracany jako 200 OK z komunikatem w treści, ukryty w przekierowaniu 302 albo w niestandardowym formacie. W mikroserwisach różne formaty błędów pozwalają ustalić, która usługa obsługuje które żądanie.

3. Brakujące, nadmiarowe i nietypowe parametry​

Testy odpowiadające konkretnym CWE z kategorii:

  • usuń parametr z żądania (CWE-234) — czy aplikacja odrzuca żądanie, czy przyjmuje wartość domyślną, która omija kontrolę?
  • dodaj parametr spoza specyfikacji albo zduplikuj istniejący (CWE-235),
  • podaj null, pustą tablicę, pusty obiekt, liczbę ujemną, zero (dzielenie przez zero — CWE-369), bardzo dużą liczbę,
  • podaj nieznaną wartość enum — np. rolę lub typ zdarzenia, którego aplikacja nie zna. Sprawdź, czy gałąź default odmawia, czy przepuszcza.

4. Fail open w kontrolach bezpieczeństwa​

Dla każdej kontroli (autoryzacja, walidacja, limit, weryfikacja tokenu, CAPTCHA) spróbuj doprowadzić ją do błędu, a nie do odmowy:

  • uszkodzony token zamiast nieprawidłowego (zły format Base64, brakujący segment JWT),
  • żądanie zasobu, który nie istnieje, w kontekście innego użytkownika — czy dostajesz 404, 403 czy 500? Różne kody to wyrocznia, która zdradza istnienie obiektów,
  • sytuacja braku uprawnień do zasobu technicznego (CWE-274, CWE-280) — np. plik lub katalog bez prawa odczytu.

Oczekiwany wynik: każdy błąd kontroli kończy się odmową (ASVS 5.0, wymaganie 16.5.3).

5. Przerwane operacje wieloetapowe​

  • Przerwij proces w połowie: zamknij połączenie po wysłaniu żądania, przekrocz timeout, wyślij krok 3 bez kroku 2.
  • Sprawdź, czy stan po przerwaniu jest spójny: czy pieniądze, punkty, rezerwacje, stany magazynowe nie zostały zmienione częściowo.
  • Wyślij to samo żądanie równolegle wiele razy — wyjątek w jednym wątku i sukces w drugim to klasyczna droga do podwójnego wykonania operacji (powiązane z wyścigami — patrz A06:2025 Insecure Design).

6. Awarie zależności​

Jeśli masz kontrolę nad środowiskiem testowym (test typu grey/white box):

  • zatrzymaj bazę, cache, kolejkę albo usługę zewnętrzną,
  • spowolnij zależność zamiast ją wyłączać — wolna zależność bywa groźniejsza niż niedziałająca, bo trzyma wątki wywołującego,
  • sprawdź, czy aplikacja w trybie awaryjnym nadal egzekwuje kontrole bezpieczeństwa (ASVS 16.5.2), np. czy brak usługi autoryzacji nie oznacza „wpuść wszystkich".

7. Wyczerpanie zasobów​

  • Wywołuj wielokrotnie operacje kończące się błędem (upload niepoprawnego pliku, nieudany import) i obserwuj zużycie pamięci, deskryptorów plików, połączeń do bazy.
  • Sprawdź, czy istnieją limity: rate limiting, maksymalny rozmiar żądania, kwoty na użytkownika.

Testy obciążeniowe uzgadniaj z właścicielem systemu — mogą wywołać realną niedostępność.

✅ Tipy testerskie​

  • Zapisuj w raporcie treść błędu i to, co z niej wynika — wersja frameworka, nazwa tabeli, ścieżka na serwerze.
  • Porównuj zachowanie tej samej operacji przy sukcesie, odmowie i błędzie — różnice są wyrocznią.
  • Skaner wykryje stack trace, ale fail open i niespójny stan to błędy logiki — wymagają testu ręcznego.

W kolejnym kroku: Weryfikacja konfiguracji aplikacji i serwera