Mishandling of Exceptional Conditions: Opis podatności i jej wpływ
A10:2025 – Mishandling of Exceptional Conditions
Nowa kategoria w OWASP Top 10:2025. Zebrano w niej 24 CWE; część z nich wcześniej trafiała do ogólnego worka „słaba jakość kodu". Według autorów OWASP osobna kategoria daje bardziej konkretne wskazówki.
OWASP opisuje problem jako trzy możliwe zaniedbania. Aplikacja:
- nie zapobiega nietypowej sytuacji,
- nie rozpoznaje jej, gdy się dzieje,
- reaguje źle albo wcale, gdy już się wydarzyła.
Za każdym razem, gdy aplikacja „nie jest pewna" swojej następnej instrukcji, wyjątkowa sytuacja została źle obsłużona — to parafraza definicji z OWASP.
Skąd się biorą sytuacje wyjątkowe?
- brakująca, słaba lub niepełna walidacja danych wejściowych,
- obsługa błędów „wysoko" (na końcu żądania) zamiast tam, gdzie błąd powstaje,
- nieoczekiwany stan środowiska: brak pamięci, brak uprawnień, awaria sieci, timeout zależności,
- niespójna obsługa wyjątków w różnych częściach kodu,
- wyjątki, których nikt nie obsłużył — system przechodzi w stan nieznany.
Najważniejsze CWE w kategorii
| CWE | Nazwa | Co to znaczy dla testera |
|---|---|---|
| CWE-209 | Generation of Error Message Containing Sensitive Information | komunikat błędu zdradza stack trace, zapytanie SQL, ścieżki, wersje |
| CWE-234 | Failure to Handle Missing Parameter | usunięcie parametru z żądania zmienia logikę |
| CWE-274 | Improper Handling of Insufficient Privileges | brak uprawnień kończy się czymś innym niż odmową |
| CWE-476 | NULL Pointer Dereference | null w miejscu obiektu wywraca proces |
| CWE-636 | Not Failing Securely ('Failing Open') | błąd kontroli bezpieczeństwa kończy się przepuszczeniem |
Pełna lista 24 CWE jest na stronie kategorii.
Fail open i fail closed
To najważniejsze pojęcie tej kategorii:
- Fail open — kontrola, która się wysypie, przepuszcza. Przykład: wyjątek przy sprawdzaniu uprawnień łapany przez ogólny
catch, po którym kod idzie dalej. - Fail closed — błąd kończy się odmową lub wycofaniem całej operacji.
Kierunek awarii nie zawsze jest oczywisty. Michał Zalewski (The Tangled Web, 2011, s. 241–253) zauważa, że mechanizmy rozluźniające reguły przeglądarki (CORS, postMessage) przy awarii wracają do starej, ostrzejszej reguły, a mechanizmy zacieśniające (CSP, sandbox, HSTS) przy awarii po cichu przepuszczają. Dlatego przy każdej kontroli warto zadać pytanie: co się stanie, gdy ten mechanizm zawiedzie albo jeden element systemu o nim nie wie?
Osobny przypadek to gałąź „wszystko inne". switch (role) z default, który daje uprawnienia zwykłego użytkownika, albo serializacja „wszystkich pól oprócz passwordHash" działają poprawnie — do dnia, w którym ktoś doda nową rolę albo nowe pole. Pominięcie nowego wariantu nie daje żadnego błędu.
Przykładowe scenariusze ataku (według OWASP)
- Wyczerpanie zasobów (DoS). Aplikacja łapie wyjątki przy uploadzie plików, ale nie zwalnia zasobów. Każdy kolejny błąd zostawia zablokowany zasób, aż skończą się wszystkie.
- Wyciek danych przez błędy bazy. Pełny błąd systemowy trafia do użytkownika. Napastnik celowo wywołuje kolejne błędy, żeby z ich treści zbudować lepszy atak SQL injection — komunikaty błędów są dla niego rekonesansem.
- Uszkodzony stan transakcji finansowej. Transakcja: obciąż konto użytkownika → uznaj konto docelowe → zapisz log. Napastnik przerywa ją w połowie (np. zakłócając sieć). Jeśli system nie wycofa całości, napastnik może opróżnić konto albo — przy wyścigu — wysłać pieniądze wielokrotnie.
🧨 Potencjalne skutki
- Ominięcie kontroli dostępu lub uwierzytelniania przez fail open,
- wyciek informacji o stosie technologicznym, strukturze bazy i usługach wewnętrznych,
- odmowa usługi przez nieobsłużony wyjątek lub wyczerpanie zasobów,
- niespójne dane po częściowo wykonanej operacji, w tym nadużycia finansowe.
Skala problemu
Dane z tabeli kategorii: 24 zmapowane CWE, średnio 2,95% testowanych aplikacji z co najmniej jednym z nich (maksymalnie 20,67%), 769 581 wystąpień i 3 416 powiązanych CVE.
✅ Dobre praktyki (skrót)
- Obsługuj błąd tam, gdzie powstaje, a dodatkowo miej globalny handler „ostatniej szansy".
- Obsługa błędów w jednym miejscu i jednym stylu — według OWASP najlepiej w całej organizacji.
- Przerwana transakcja = wycofanie całości (fail closed), nie próba naprawy w połowie.
- Użytkownik dostaje ogólny komunikat, szczegóły idą do logów, powtarzające się błędy do alertów (A09:2025).
- Limity wszędzie: rate limiting, kwoty zasobów, timeouty. Według OWASP nic w IT nie powinno być nieograniczone.
W kolejnym kroku: Metody testowania podatności