Testy penetracyjne aplikacji online

13.02.2013 Marcin Sałaciński Tagi: , ,

W jednym z pierwszych artykułów tu opublikowanych wspomniałem o typowych podejściach do udostępnianiu aplikacji i systemów ulokowanych wewnątrz sieci firmowej dla użytkowników zewnętrznych. Jak już pisałem, rozwiązania techniczne – komponenty sprzętowe i odpowiednie zapory – uniemożliwiające włamania do sieci i uzyskanie nieautoryzowanego dostępu do zasobów są oczywiście niezbędne i zapewniają odpowiedni poziom ochrony. W tym miejscu kończy się rola DMZ, a odpowiedzialność spoczywa na samym wystawianym w świat oprogramowaniu. Od jego jakości i zastosowanych mechanizmów zależy, czy aplikacja jest bezpieczna i nie będzie powodować wycieków danych.

To, jak jest napisany kod aplikacji, bezpośrednio wpływa na zabezpieczenia danego rozwiązania i jego podatność na potencjalne ataki. Wykwalifikowany programista nie tylko dba o jakość funkcjonalności systemu, ale także z reguły wie, jakie wzorce lub konstrukcje funkcji i poleceń w stosowanym języku programowania są zagrożeniem. Jeżeli zespół jest pod presją czasu lub brakuje mu wiedzy i doświadczenia, może się zdarzyć uproszczenie, czy przeoczenie, które może być katastrofalne w skutkach i otworzyć furtkę dla niepowołanych osób. Zdarza się też, że pewne braki systemu lub funkcjonalności mogące powodować zagrożenie są celowo wdrażane z powodu ograniczeń budżetu projektu, braku możliwości zmian funkcjonalnych w końcowym etapie wdrożenia, lub z wielu innych powodów. Wtedy jednak najczęściej osoby akceptujące uruchomienie takiego rozwiązania są tego faktu świadome (a przynajmniej powinny być), a zmiany podwyższające poziom bezpieczeństwa mogą być wdrożone później lub wcale.

Przykłady zagrożeń

Przykładem potencjalnie niebezpiecznej funkcjonalności może być formularz logowania w aplikacji dostępnej publicznie umożliwiający nieograniczoną liczbę prób z różnymi kombinacjami loginu i hasła. Tu powinna być obecna blokada możliwości zalogowania np. na 10 minut na dane konto po trzech nieudanych próbach (niby nic ale już mocno utrudnia ataki siłowe), nie zawsze jednak jest opłacalne stosowanie bardzo mocnych zabezpieczeń w takich systemach. Kolejny przykład, tym razem ewidentnego przeoczenia – możliwość zmiany parametru w linku do serwisu i podgląd wiadomości innych osób (jak to było możliwe w sylwestra na facebooku). Przykłady można mnożyć i wymieniać, ale cel jest jeden – zabezpieczenie systemu publicznego na tyle, na ile to możliwe w ramach posiadanych środków. A nawet najlepsze zespoły programistów nie są w stanie przewidzieć wszystkiego w obecnych skomplikowanych i wielowarstwowych aplikacjach.

Czym są testy penetracyjne?

Firmy posiadające polityki bezpieczeństwa, a nawet procedury cyklicznej weryfikacji jakości systemów podchodzą do tematu w aktywny sposób, nie czekając na złamanie zabezpieczeń  systemów (i zdarzające się propozycje sprzedaży informacji o znalezionych przez włamywaczy lukach). Najlepszym i najskuteczniejszym sposobem jest przeprowadzenie testów bezpieczeństwa przez odpowiednich specjalistów. Są to znane testy penetracyjne (w skrócie pen-testy). Pozwalają one poprzez metodyczne działanie odnaleźć wszelkie znane podatności i luki w aplikacji, jednocześnie dając możliwość wyjścia naprzeciw potencjalnym atakom.

Rodzaje testów

Do tych testów można podejść na kilka sposobów, z których najbardziej znane są dwa:

  • Testy black-box – testerzy/specjaliści próbują się włamać do systemu traktując go jako aplikację, o której mają tylko ogólną wiedzę (np. sam link do systemu) i symulując atak z zewnątrz przez obce osoby
  • Testy crystal-box (lub white-box) – testerzy mają komplet informacji o samym systemie, jego architekturze, a nawet mają dostęp do środowiska uruchomieniowego i wgląd do dokumentacji i kodów źródłowych

Rodzaj stosowanych testów zależy od posiadanych funduszy i dostępnego czasu. O ile testy black-box mogą być zautomatyzowane i próbować zidentyfikować typowe lub powszechnie znane podatności, to testy crystal/white-box wymagają więcej zaangażowania, analizy kodów, weryfikacji konfiguracji systemu itp. Oznacza to wprost dłuższy czas realizacji i wyższe koszty.
Testy black-box można stosować częściej i pozwalają zweryfikować, jakie możliwości ma potencjalny włamywacz z zewnątrz. Drugi rodzaj testów umożliwia dogłębną analizę systemu i wyłapanie wszelkich zagrożeń, nawet jeśli ryzyko ich wystąpienia przez dostęp z zewnątrz jest minimalne lub żadne.

Raport z testu

W wyniku przeprowadzenia takiego testu (niezależnie od jego rodzaju) otrzymujemy najczęściej szczegółowy raport opisujący poszczególne stwierdzone podatności wraz z dodatkowymi informacjami. Przykładowo struktura takiego dokumentu może wyglądać jak poniżej:

  1. Opis zrealizowanych działań i zakres testów
  2. Zidentyfikowane podatności
    1. Podatność 1
      1. Opis podatności
      2. Status (potwierdzona/niepotwierdzona)
      3. Krytyczność (np. w skali 1-5)
      4. Opis zagrożeń
      5. Rekomendacje/zalecenia naprawcze
    2. Podatność 2

Wnioski

Raport może być sformułowany inaczej niż powyżej – najważniejsze, żeby opisywał dokładnie co zostało zweryfikowane i w jaki sposób, czy udało się stwierdzić jakieś podatności (a w tej sytuacji powinny zostać opisane ich właściwości, poziom zagrożenia itp.), a także jakie są zalecenia i propozycje ich wyeliminowania i doprowadzenia do stanu, gdy nie będą już mogły spowodować zagrożenia systemu.
Dla przykładu omawianego wcześniej (z brakiem blokady logowania po kilku próbach) zaleceniem może być wdrożenie mechanizmu zliczającego próby i włączającego blokadę i zliczanie określonego czasu po osiągnięciu limitu (lub np. wyświetlenie kodu potwierdzającego – captcha).

Testy penetracyjne powinny być realizowane okresowo, np. raz w roku, niezależnie od rozwoju aplikacji. Może się zdarzyć, że pomimo braku zmian funkcjonalnych odkryte zostaną nowe zagrożenia dla wykorzystanej technologii i mogą być nowe luki i podatności. A już na pewno warto je realizować, jeżeli aplikacje są w ciągłym rozwoju i wprowadzane są nowe funkcjonalności, które mogą za sobą pociągnąć także wiele niepożądanych niedoróbek i dziur zabezpieczeń. Każdy taki test nie jest tani i jest czymś w rodzaju ubezpieczenia – nawet jeśli nie wykryte będą żadne problemy, jest to cenna informacja i świadczy o wysokiej jakości systemu. Niestety nadal wiele firm i właścicieli stron kompletnie nie dba o zapewnienie bezpieczeństwa lub świadomie ignoruje możliwość włamań.

avatar
IT Project Manager
Kierownik projektu, analityk i projektant z szeroką wiedzą techniczną i doświadczeniem w procesie tworzenia oprogramowania, zdobytymi w trakcie realizacji projektów, także dofinansowywanych z UE.

2 odpowiedzi na “Testy penetracyjne aplikacji online”

  1. avatar diamond napisał(a):

    Good post. I’d been checking regularly this web site and I’m fascinated! Very useful info specially the last area :) I manage such information a great deal. I used to be interested in this particular data for an extended time. Appreciate it and all the best ..

  2. avatar moderngold napisał(a):

    Hello there, You could have performed an admirable job. Let me definitely delicious the idea in addition to personally recommend to be able to my friends. I am sure are going to took advantage of this site.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *