Paweł Goleń, blog

Raz na jakiś czas spotykam się z mechanizmem, którego przeznaczenia nie rozumiem. Albo inaczej - nie jestem w stanie zrozumieć, dlaczego ktoś myśli, że ten mechanizm będzie działać. Na przykład ładnych już kilka lat temu w trakcie pracy nad projektem pewnej aplikacji jej dostawca zaproponował, by wprowadzić dodatkową warstwę szyfrowania przy przesyłaniu formularzy na serwer. Połączenie z serwerem miało być oczywiście realizowane standardowo przy pomocy SSL, natomiast jeszcze sama aplikacja po stronie klienta miała szyfrować dane przed ich wysłaniem do serwera. Miało to być zabezpieczenie przed atakiem typu man-in-the-middle. Ostatecznie funkcja ta nie została zaimplementowana, i dobrze.

W końcu udało mi się wybrać na dłuższą trasę. Zrobiło się z tego trochę ponad 60 kilometrów, a trasa prowadziła przez cztery dolinki podkrakowskie, Dolinę Prądnika, Dolinę Sąspowską (z małym odbiciem na Złotą Górę), Dolinę Będkowską i Dolinę Kobylańską. Na siłę można jeszcze wspomnieć Dolinę Szklarki, ale to ledwie początek był.

W sumie miałem ochotę jeszcze przeskoczyć przez Dolinę Bolechowicką lub Dolinę Kluczwody, ale jednak słońce dało mi się już we znaki...

Dziś będzie krótko. Na początek odsyłam do tekstu, do którego chcę się odnieść: A czy Twój bank jest odporny na ataki UI Redressing – Clickjacking? A teraz konkretniej - ja z UI Redressing mam pewien problem. To jest doskonała podatność do pokazywania na konferencjach, szkoleniach, prezentacjach. Jest bardzo efektowna, ale już z jej efektywnością bywa różnie. Tekst, do którego odsyłam, dotyczy bankowości internetowych. Obawiam się, że w tym konkretnym przypadku z efektywnością (czyli skutecznością) tego typu ataku byłoby bardzo słabo.

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...