Dlaczego warto oznaczać błędy bezpieczeństwa

Na spotkaniu SPINu mówiłem między innymi o tym, że błędy związane z bezpieczeństwem powinny być w bazie błędów oznaczane tak, by było wiadomo, że jest to błąd bezpieczeństwa oraz powinny zawierać informację o powodzie tego błędu (w sensie root cause). Dziś mogę przytoczyć kolejny argument za tym, by takie znakowanie błędów bezpieczeństwa prowadzić.

Gdyby zastanowić się nad tym, czym jest aplikacja (w domyśle) internetowa i co powinno być testowane, może pojawić się problem. Na dobrą sprawę by system działał wykorzystywanych jest wiele komponentów. Sprzęt, system operacyjny, serwer HTTP, serwer aplikacyjny, (...). Sama aplikacja też nie jest tworzona od podstaw, wykorzystany jest jakiś framework, biblioteki, dodatkowe moduły. Każdy z tych składników wpływa na bezpieczeństwo całego rozwiązania (patrz: Remember the Giblets!).

Co zrobić w sytuacji, gdy pojawia się nowa wersja jednego z takich składników? Czy trzeba zawsze mieć najbardziej aktualną wersję? Właściwie pytanie powinno brzmieć nie tyle, czy trzeba, ale czy można. W końcu system jest przetestowany w konkretnej konfiguracji i działa, a przynajmniej powinien, działać w niej prawidłowo. Pogoń za najbardziej aktualną wersją nie tylko nie jest uzasadniona, może być wręcz szkodliwa. By nie szukać daleko, w pewnej chwili jeden z moich przykładów opublikowanych w ramach przewodnika po bezpieczeństwie aplikacji internetowych przestał działać prawidłowo. Podatność, która w nim była, nagle zniknęła. Dlaczego? Bo zmieniła się wersja jednego komponentów, z którego przykład korzystał (patrz: Dlaczego przykład przestał działać).

Typowym i uzasadnionym w sumie podejściem jest zasada jeśli coś działa, to lepiej tego nie ruszać. Jeśli system pracujący z biblioteką foobar w wersji 1.3.1 działa poprawnie od lat kilku, to po co zmieniać ją na wersję 1.3.15 lub 1.4.1? Powodów może być kilka, na przykład:

W przypadku bibliotek nowa funkcjonalność raczej nie zostanie wykorzystana, bo kod, który z tej biblioteki korzysta, tej nowej funkcjonalności nie jest świadomy. Ten przypadek odłóżmy więc na bok. Temat zwykłych błędów też jest ciekawy. Nie każdy z błędów zawsze się ujawnia, więc jeśli aplikacja działa stabilnie i bez problemów, powodów do zmiany wersji biblioteki też raczej nie ma.

A co w przypadku błędów bezpieczeństwa? Tu również fakt istnienia znanego błędu bezpieczeństwa nie musi implikować konieczności zmiany wersji biblioteki. Być może ten błąd będzie zupełnie nieistotny w przypadku jakiegoś konkretnego systemu. Problem w tym, że by się o tym przekonać, dobrze jest wiedzieć, że jakiś błąd jest błędem bezpieczeństwa właśnie. I tu pojawia się problem...

Proponuję w ramach eksperymentu przejrzeć changelogi bibliotek, aplikacji czy serwisów, z których korzystacie. Przy okazji można też sprawdzić bazy błędów typu Open Source Vulnerability Database czy National Vulnerability Database. Cel ćwiczenia jest prosty, znalezienie odpowiedzi na kilka pytań:

Powodzenia :)

Oryginał tego wpisu dostępny jest pod adresem Dlaczego warto oznaczać błędy bezpieczeństwa

Autor: Paweł Goleń