Podatności

Niniejszy artykuł tłumaczy czym są podatności i omawia ich występowanie we wszystkich systemach.

Podatność to słabość systemu, która może zostać wykorzystana do naruszenia poufności, integralności i/lub dostępności. Podatności można kategoryzować na wiele sposobów. W tym artykule użyjemy trzech kategorii najwyższego ryzyka: usterki oprogramowania, problemy przy konfiguracji zabezpieczeń i nadużycie funkcji oprogramowania. Kategorie te zostały umówione poniżej.

Kategorie podatności

Usterki oprogramowania są wynikiem niezamierzonego błędu w architekturze lub samym kodzie oprogramowania. Jako przykład może posłużyć błąd przy weryfikacji wprowadzanych danych, np. kiedy dane wprowadzane przez użytkownika nie są prawidłowo sprawdzane pod kątem prób wprowadzania szkodliwych stringów używających nieporządanych znaków czy zbyt długich wartości wiązanych ze znanymi atakami. Inny przykład to błąd dopuszczający sytuację wyścigu ("race condition"), przez który atakujący może przeprowadzić określone działanie posiadając podniesione uprawnienia.

Ustawienia konfiguracji bezpieczeństwa to element bezpieczeństwa oprogramowania który może zostać zmieniony przez samo oprogramowanie. Przykłady ustawień to np. system operacyjny oferujący dostęp do listy kontrolnej przydzielającej prawa użytkowników do odczytu i modyfikacji plików oraz np. aplikacja dopuszczająca umożliwianie lub uniemożliwianie szyfrowania danych wrażlliwych znajdujących się w aplikacji.

Problemy przy konfiguracji zabezpieczeń to m.in. używanie ustawień konfiguracji bezpieczeństwa w sposób, który ma negatywny wpływ na bezpieczeństwo oprogramowania.

Cecha oprogamowania to możliwość funkcyjna udostępniona przez oprogramowanie. Podatność na nadużycie funkcji oprogramowania to taki typ podatności, w której dana funkcja stanowi dziurę bezpieczeństwa systemu. Tego typu podatności stwarza projektant oprogramowania, gdy aby uzyskać dodatkowe funkcje oprogramowania zakłada idylliczny scenariusz i ryzykuje tym samym podatność na ewentualne ataki.

Na przykład, oprogramowanie klienckie email może zawierać funkcjonalność, która umożliwia wyrenderowanie treści HTML w wiadomościach email. Atakujący może w tej sytuacji stworzyć fałszywy mail zawierający hiperlink, który po wyrenderowaniu w HTML wygląda na nieszkodliwy, a w rzeczywistości po kliknięciu przekierowuje odbiorcę na szkodliwą stronę. Jednym z idyllicznych założeń w fazie projektowania funkcji renderowania treści HTML była myśl, że użytkownicy nie otrzymają szkodliwych hiperlinków i nie będą w nie klikać.

Podatności nadużycia funkcji oprogramowania pojawiają się podczas projektowania oprogramowania lub jego komponentów (np. protokół, który oprogramowanie wdraża). Idylliczne założenia mogą być oczywiste - np. projektant jest świadomy słabości bezpieczeństwa i zakłada, że oddzielna kontrola bezpieczeństwa wystarczy.

Często jednak założenia idylliczne są dwuznaczne, chociażby utworzenie funkcji bez wcześniejszego ocenienia ryzyka. Dodatkowo zagrożenia mogą się zmieniać w czasie życia oprogramowania czy protokołu w nim użytego.

Przykład? Address Resolution Protocol (ARP) zakłada, że odpowiedź ARP zawiera prawidłowe mapowanie pomiędzy adresami Media Access Control (MAC) a Internet Protocol (IP). Cache ARP używają tej informacji, by umożliwić przydatne działanie - zezwolenie na wysyłanie danych pomiędzy urządzeniami w jednej sieci lokalnej. Jednakże atakujący mógłby wygenerować fałszywe komunikaty ARP celem zmylenia tabli systemowej ARP i w ten sposób przeporwadzić atak denial-of-service lub man-in-the-middle attack.

Protokuł ARP został ustandaryzowany ponad 25 lat temu, a zagrożenia znacząco się od tego czasu zmieniły, więc założenia idylliczne, które były wówczas nie do uniknięcia dziś nie mają już raczej racji bytu.

Może być ciężko odróżnić podatność nadużycia funkcji oprogramowania od pozostałych dwóch kategorii. Np. zarówno podatności związane z wadami, jak i nadużyciami mogą wynikać z braków w procesie projektowania oprogramowania. Jednakże wady oprogramowania są jednoznacznie negatywne - nie mają cech pozytywnych w odniesieniu do bezpieczeństwa czy funkcjonalności - podczas gdy podatności na nadużycia funkcji oprogramowania są wynikiem dostarczania dodatkowych funkcji.

Mogą mylić podatności na nadużycia w odniesieniu do funkcji, które można odblokowywać lub zablokowywać - w rozumieniu, że są konfigurowalne - a kwestie konfiguracji bezpieczeństwa. Kluczową różnicą jest to, że przy podatności na nadużycia ustawienia bezpieczeństwa umożliwiają lub blokują całą funkcję, a nie wpływają jedynie na bezpieczeństwo. Podatność wynikająca z konfiguracji bezpieczeństwa dotyczy wyłącznie bezpieczeństwa.

Np. ustawienie blokujące używanie HTML w mailach ma ogromny wpływ na zarówno kwestię bezpieczeństwa, jak i funkcjonalności. W tym przypadku podatność w odniesieniu do ustawienia będzie podatnością związaną z nadużyciem. Ustawienie blokujące funkcję antiphishingową w kliencie pocztowym ma ogromny wpływ wyłącznie na bezpieczeństwo, więc podatność dot. takiego ustawienia byłaby określona jako podatność w związku z konfiguracją bezpieczeństwa.

Obecność podatności

Żaden system nie jest w 100% bezpieczny: każdy system ma podatności. W danym momencie system może nie posiadać żadnych widocznych wad, ale podatności na problemy z konfiguracją bezpieczeństwa i nadużycia funkcji oprogramowania są zawsze obecne.

Podatność na nadużycia w przypadku funkcji oprogramowania jest nieodłączna, ponieważ każda funkcjonalność musi być opierana na założeniach idyllicznych - a te założenia mogą zostać złamane mimo dołożenia ogromnych wysiłków i poniesienia sporych kosztów. Kwestie konfiguracji bezpieczeństwa są nie do uniknięcia z dwóch powodów.

Po pierwsze, wiele ustawień konfiguracyjnych zwiększa bezpieczeństwo kosztem funkcjonalności, więc używanie najbezpieczniejszych ustawień może doprowadzić do bezużyteczności oprogramowania. Po drugie, wiele ustawień bezpieczeństwa ma zarówno pozytywne, jak i negatywne kosekwencje względem bezpieczeństwa.

Przykładem jest dopuszczona liczba następujących po sobie, nieudanych prób logowania na konto użytkownika zanim zostanie ono zablokowane. Ustawiając ją na 1 uzyskalibyśmy najbezpieczniejszą opcję przeciw atakom opartym na zgadywaniu haseł, ale jednocześnie blokowalibyśmy legalnych użytkowników po tym, jak jednokrotnie wpisaliby złe hasło. Co więcej, prawdopodobnie zachęciłoby to do używania przez atakujących ataków typu denial-of-service z racji łatwości generowania pojedynczej, nieudanej próby logowania dla wszystkich kont użytkowników.

Z powodu liczby nieuniknionych podatności w ustawieniach konfiguracji bezpieczeństwa i możliwości nadużyć funkcji oprogramowania plus liczby podatności na wady oprogramowania w systemie niezależnie od czasu, każdy system może posiadać dziesiątki, jak nie setki podatności w jednym tylko systemie.

Te podatności prawdopodobnie posiadają zróżnicowane cechy. Część będzie łatwa do wykorzystania, podczas gdy inne będą możliwe do wykorzystania jedynie w sytuacji zaistnienia kombinacji wysoce nieprawdopodobnych warunków.

Jedna podatność może skutkować dostępem do systemu na poziomie administratora, podczas gdy inna jedynie umożliwiać odczyt nieistotnego pliku.

Ostatecznie organizacje muszą wiedzieć, jak trudno jest wykorzystać daną podatność i co się stanie w sytuacji, jeśli dojdzie do jej wykorzystania.

Podatności stron WWW

OWASP lub Projekt Bezpieczeństwa Otwartej Sieci (Open Web Security Project) to organizacja non-profit skoncentrowana na zwiększaniu bezpieczeństwa oprogramowania i aplikacji WWW. Wg Open Web Application Security Project pod względem popularności XSS był siódmą z najczęściej spotykanych podatności aplikacji WWW w roku 2017.

Organizacja publikuje listę najważniejszych podatności aplikacji WWW bazując na danych z różnych organizacji bezpieczeństwa.

Podatnosci aplikacji WWW są priorytetowane pod względem możliwości wykorzystania, wykrywalności i wpływu na oprogramowanie, którym może być każdy CMS, jak WordPress, Joomla, Magneto, Woocommerce i inne.

Poniżej przedstawiamy sześć najpopularniejszych podatności stron WWW, przed którymi musisz się chronić.

1. SQL Injections
2. Cross Site Scripting (XSS)
3. Broken Authentication & Session Management - IdentityManager
4. Insecure Direct Object References - DOM (Document Object Model)
5. Security Misconfiguration
6. Cross-Site Request Forgery (CSRF)

Zobacz również

Informacja o dokumentacji źródłowej

  • Autorzy: Elizabeth LeMay, Karen Scarfone i Peter Mell
  • Tytuł: National Institute of Standards and Technology (NIST) Interagency Report 7864, The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities
  • Data ostatniej modyfikacji: July 2012
  • Informacja o prawach autorskich: Niniejszy dokument nie podlega prawom autorskim.