O wyższości defektu bezpieczeństwa nad defektem funkcjonalnym

Choć oba typy defektów mogą prowadzić do problemów, to defekty bezpieczeństwa, ze względu na swoje potencjalne konsekwencje, często dostają dużo większą, a wręcz szczególną uwagę. W tym artykule przyjrzymy się bliżej temu zagadnieniu, analizując różnice między tymi dwoma rodzajami defektów oraz wyjaśniając, dlaczego defekty bezpieczeństwa są często traktowane jako priorytetowe.
 
Czy potrzebujemy jakichś specjalnych dowodów na poparcie tezy, że defekty bezpieczeństwa są traktowane „lepiej”? 

1. W programach typu bug bounty zazwyczaj zachęca się do poszukiwania defektów bezpieczeństwa. 
2. W modelu pay-per-bug stawki za defekty bezpieczeństwa zazwyczaj są od 100 do 1000 razy większe niż za defekty funkcjonalne.
3. Najbardziej spektakularne wypłaty za znalezione defekty prawie zawsze dotyczą defektów bezpieczeństwa.
4. Defekty bezpieczeństwa trafiają na nagłówki mediów tradycyjnych.
5. Specjaliści od bezpieczeństwa są najlepiej opłacani w branży IT.

Chyba nie trzeba pisać więcej. 

Dlaczego tak jest?

Bezpieczeństwo oprogramowania jest priorytetowe, ponieważ defekty w tym obszarze mogą prowadzić do poważnych konsekwencji, takich jak:

• utrata danych - hakerzy mogą uzyskać dostęp do poufnych informacji, takich jak dane osobowe, finansowe lub medyczne, co może prowadzić do kradzieży tożsamości, oszustw finansowych lub naruszenia prywatności
• naruszenie integralności danych - atakujący mogą modyfikować lub usuwać dane, co może prowadzić do problemów w funkcjonowaniu firmy lub organizacji, a także do strat finansowych
• przestoje w działaniu - ataki hakerskie mogą spowodować awarię systemów, co prowadzi do przestojów w działaniu firmy lub organizacji, a także do strat finansowych
• utrata reputacji - wyciek danych lub awaria systemu mogą negatywnie wpłynąć na reputację firmy lub organizacji, co może prowadzić do utraty klientów i partnerów biznesowych
• kary finansowe - w niektórych branżach, takich jak sektor finansowy lub medyczny, firmy są zobowiązane do przestrzegania surowych przepisów dotyczących bezpieczeństwa danych. Naruszenie tych przepisów może prowadzić do poważnych kar finansowych.

W przeciwieństwie do defektów funkcjonalnych, które zazwyczaj powodują problemy z działaniem oprogramowania, defekty bezpieczeństwa mogą być wykorzystane przez hakerów do przeprowadzenia ataków, które mogą mieć poważne konsekwencje dla użytkowników i firm. Dlatego też bezpieczeństwo oprogramowania jest priorytetem dla programistów i firm, które chcą chronić swoje dane i reputację.

Jak my testerzy możemy na tym skorzystać?

Poniżej garść przykładów i wskazówek, jak możemy wykorzystać w swojej pracy i codziennym życiu potencjał defektu bezpieczeństwa.

1. Masz problem z uzyskaniem poprawki dla zgłoszonego defektu? Przekonaj, że jest to defekt bezpieczeństwa. Wiele organizacji kategoryzuje defekty, a te z łatką „security” często z automatu dostają najwyższe prio lub łatkę „fix now”. Wystarczy, że znajdziesz uzasadnienie ryzyka bezpieczeństwa dla defektu i możesz liczyć na szybszą poprawkę.
2. Tak, jak pisaliśmy, najlepiej zarabiają specjaliści od bezpieczeństwa. Chcesz dobrze zarabiać? Zostań jednym z nich. Może to wymaga poświecenia dużej liczby godzin na kursach i na pogłębianiu wiedzy, ale masz duże szanse na to, że Ci się to opłaci.
3. Jeśli jesteś testerem juniorem, który nie dostał jeszcze szansy na pracę w zawodzie, to warto zwrócić się ku testom bezpieczeństwa. W przerwach między pojawianiem się nowych ogłoszeń o pracę i wysyłaniem CV możesz pogłębiać swoją wiedzę, a każdą nowo przyswojoną informację przekuwać na testy na systemach. Jeśli znajdziesz defekt raportuj go firmom, na stronach których lub w aplikacjach których został on znaleziony. Pamiętaj, że polskie prawo nie tylko zachęca, ale nawet przymusza Cię, by raportować każdy defekt bezpieczeństwa właścicielom strony. Często jest tak, że zgłoszenia defektów funkcjonalnych gubią się w korespondencji między adminem, a developerem, za to na defekt bezpieczeństwa zawsze dostaniesz odpowiedź. Jeśli Twój defekt dostanie poprawkę, to może i Ty dostaniesz szansę na pracę. Rozważ również przystąpienie do programów bug bounty. A nuż uda Ci się wygrać jakąś atrakcyjną nagrodę.
4. Jesteś doświadczonym testerem. Twoje raporty defektów bezpieczeństwa podnoszą Twoją rangę w organizacji i dają Ci większy szacunek wśród programistów. Nie musisz mówić, że znalezione defekty są wynikiem uruchomienia analizatora podatności. Bylebyś rozumiał na czym polega defekt i potrafił to wyjaśnić zespołowi. Twoje akcje natychmiast szybują w górę, a przed Tobą awanse i podwyżki. A przynajmniej określnie „niezastąpionego”. 
5. Wyobraź sobie, że posiadane przez Ciebie oprogramowanie albo produkt zawierający oprogramowanie już dawno utracił wsparcie i gwarancję. Następuje awaria, która ewidentnie jest jakimś problemem programistycznym, ale wiesz, że nikt Ci tego produktu za darmo nie naprawi. Co trzeba zrobić? Trzeba zgłosić problem jako podatność w oprogramowaniu i jeśli jest się wystarczająco przekonywującym to może uda się uzyskać poprawkę, a może nawet najnowszą wersję. Taki przypadek został ostatnio opisany przez jednego z naszych czytelników. Problem polegał na tym, że uszkodzony plik konfiguracji wprowadzał urządzenie w niekończący się reset (aplikacja podnosi się i podczas podnoszenia znów się restartuje). Docelowo doprowadziło to do uszkodzenia hardware'u i zniszczenia urządzenia. Urządzanie było używane od 5 lat i już dawno było po gwarancji. Czytelnik spróbował zamienić ten zwykły defekt funkcjonalności, polegający na tym, że aplikacja nie waliduje uszkodzonego pliku konfiguracji lub nie potrafi go wyczyścić, by wrócić do ustawień fabrycznych w defekt bezpieczeństwa. Został zgłoszony jako problem polegający na tym, że „specjalnie” spreparowany plik konfiguracji przesłany na urządzenie może doprowadzić do uszkodzenia urządzenia. Nie wiemy czy to zadziałało, ale plan brzmi iście szatańsko. 

Pamiętaj, że „bezpieczeństwo” to hasło dostępu do wielu obszarów w IT. Menadżerowie i administratorzy boją się go, ponieważ dla nich pochodzi ze styku magii i wiedzy technicznej. Najmniejszy komponent to „defekt bezpieczeństwa”, który jeśli jeszcze nie istnieje, jest „ryzykiem bezpieczeństwa”, a jeśli istnieje, a jeszcze nie został użyty (jawnie), nazywamy „podatnością”. Jeśli masz o nim wiedzę, to z automatu dostajesz narzędzie zarabiania i rozwiązywania problemów.