Paweł Goleń, blog

Wdałem się ostatnio w nieco dziwną dyskusję odnośnie tego, czy każdy wyjątek występujący w aplikacji powinien być obsłużony. Dla uściślenia chodzi mi tutaj o aplikacje webowe i wyjątki występujące w wyniku manipulacji przez użytkownika przekazywanymi danymi.

Moim zdaniem obsługiwanie każdego wyjątku na siłę po to, by było “ładnie” nie jest dobrym pomysłem. Na przykłada dlatego, że do obsługi takiego wyjątku potrzeba jakiegoś kodu, a im więcej linii kodu, tym większe prawdopodobieństwo wystąpienia błędu. Jeszcze gorsze rzeczy mogą się dziać, jeśli kod obsługi wyjątku będzie usiłował “naprawić” sytuację wyjątkową i kontynuować wykonanie kodu (i to nawet wówczas, gdy nie ma to większego sensu). W takich przypadkach często jest lepiej po prostu przerwać wykonanie kodu, a nieobsłużony wyjątek robi to zwykle dość skutecznie.

Oczywiście można też patrzeć na sprawę w inny sposób. Co się stanie, jeśli wyjątek wystąpi w trakcie jakiejś operacji? Być może jakiś obiekt/proces/cokolwiek zostanie wówczas w osieroconym stanie i być może będzie można to w jakiś sposób wykorzystać. Pomijam tu również sytuację, gdy nieobsłużony wyjątek skutkuje wyświetleniem jakże przydatnych dla atakującego informacji (stacktrace).

Zacznę od stwierdzenia, które powtarzam tak często, jak tylko mam okazję. Bezpieczeństwo nie jest celem samym w sobie, bezpieczeństwo musi czemuś służyć. To “coś” to niekoniecznie jest dobre samopoczucie bezpieczników. Celem aplikacji jest realizowanie jej celów biznesowych z zachowaniem akceptowalnego poziomu ryzyka. W wielu miejscach pewne rzeczy można zrobić lepiej. Widziałem ważne mechanizmy bezpieczeństwa, które są zaimplementowane źle. Widziałem pozorne mechanizmy bezpieczeństwa (ach ten security theater) zaimplementowane źle, widziałem też kompletnie nieprzydatne mechanizmy bezpieczeństwa (rozwiązujące nie ten problem, co trzeba), które akurat zostały zaimplementowane dobrze...

Dziś po TKonferencji jedna osoba pytała się mnie, jak bezpiecznie przechowywać salt użyty przy hashowaniu hasła w bazie. Odpowiedź brzmi – salta nie trzeba przechowywać bezpiecznie, ponieważ jest jawny. Albo inaczej – dostęp do bazy danych trzeba ograniczać (co jest oczywiste), jednak sam salt nie wymaga specjalnej ochrony.

Kryptografia jest ważna, ale to nie jest magic dust , którym wystarczy posypać system, by stał się on automatycznie bezpieczny. Z kryptografii należy korzystać, ale trzeba znać jej ograniczenia. Niestety, w trakcie testów często spotykam się z sytuacją, w której kryptografia jest użyta w sposób nieprawidłowy. Dziś trochę na ten temat.

Czasami dostaję pytanie, co robię, gdy znajdę jakąś podatność. Oczywiście mowa o sytuacji, kiedy zdarzy mi się coś znaleźć poza działaniami związanymi z realizacją zleceń. W moim przypadku odpowiedź jest prosta – nic. Po prostu “po pracy” nie szukam podatności, a jak coś mi się rzuca w oczy, to po prostu zamykam jedno oko i udaję, że drugim tego nie widzę. Dlaczego?

Odpowiedź na to pytanie również jest dość prosta i można ją przedstawić prostym akronimem CY(O)A. Jeśli organizacja nie ma jasno określonego programu bug bounty , wolę nie sprawdzać organoleptycznie w jaki sposób potraktuje informację o podatności. Wolę nie być później w sytuacji, w której będę musiał udowodnić, że nie jestem wielbłądem.

Jeśli zastanawiasz się o co chodzi w tytule tego wpisu, to spieszę wyjaśnić, że o nic. Po prostu nie miałem pomysłu jak go zatytułować, więc wygenerowałem sobie coś takiego :) A to dlatego, że wpis ten nie ma żadnego konkretnego tematu. No dobrze, może i ten tytuł ma pewien ukryty sens, ale to mocno poboczna sprawa.

Przynajmniej dwie osoby rozwiązały moje wyzwanie, to znaczy rozwiązały wszystkie pierwotnie opublikowane zadania, nie mam na razie żadnych informacji odnośnie zadania siódmego. Oczywiście zadania rozwiązać mogło więcej osób, mogły się po prostu nie pochwalić :) Feedback jest znikomy, choć raczej pozytywny:

Thanks for the nice challenges, really enjoyed it, especially number 5 was really good. Just solved the last one (...)

Czekam na więcej :)