14:20
13/1/2017

Jeżeli dbasz o jakość swojego oprogramowania, to z pewnością posiadasz przygotowany zestaw automatycznych skryptów testowych. Warto pójść o jeden, niewielki krok dalej i spowodować, żeby testy którymi już dysponujesz, brały także pod uwagę aspekty bezpieczeństwa. Ten cel można osiągnąć przy pomocy jednego z prostych w implementacji i darmowych narzędzi z projektu OWASP: ZAP-a. Nie bez znaczenia jest też fakt, iż ZAP posiada otwarty kod źródłowy.

Instalacja i konfiguracja OWASP ZAP

OWASP Zed Application Proxy zadziała zarówno na twoim Windowsie, Macu jak i Linuxie. Po krótkiej instalacji, wszystko co musisz zrobić, to ustawić w ZAP-ie parametry serwera proxy, przez które przepuścisz ruch z Twoich skryptów testowych (np. Selenium). Dzięki temu, równolegle do wykonywania standardowych testów funkcjonalnych, otrzymasz dodatkowe informacje na temat bezpieczeństwa aplikacji pochodzące z modułów ZAP-a. Poniżej prezentujemy wizualizację pokazującą, jak wygląda przepływ danych pomiędzy omawianymi narzędziami.

Aby przygotować ZAP-a do pracy zastosuj się do następujących wskazówek. Z górnego menu otwartej aplikacji wybierz Narzędzia -> Opcje:

Konfiguracja ustawień proxy

Konfiguracja ustawień proxy

a następnie odszukaj w opcjach “Proxy lokalne” i upewnij się, że wskazuje na “localhost” oraz odpowiedni port. UWAGA! Jeżeli pod tym portem masz już uruchomioną jakąś usługę, to śmiało możesz zmienić port dla ZAP-a na inny.

I na tym właściwie możemy zakończyć temat podstawowej konfiguracji ZAP’a. Warto dodać, że jeśli pracujesz w środowisku korporacyjnym i połączenie z internetem wymaga użycia serwera proxy, to w ZAP-ie także możesz ustawić tzw. “upstream proxy” w opcji Proxy Chain / Outgoing Proxy.

ZAPa zostawiasz otwartego w tle — wrócimy do niego za chwilę.

Powiązanie ZAP-a z Selenium

W kolejnym kroku, musisz nakierować swojego drivera na ZAP-a. Aby to osiągnąć, ustaw w swoim driverze adres proxy i port proxy, jak ten który podałeś w ZAP-ie. W zależności od frameworka, można to osiągnąć na wiele sposobów. Możesz zdefiniować adres proxy w kodzie podczas konfiguracji nowego drivera (tu znajdziesz przykłady kodu dla Selenium) lub ustawić je w profilu samej przeglądarki, do której podpiąłeś drivera (tu więcej wskazówek).

Uruchom testy tak jak zwykle. Zwróć uwagę, że w trakcie wykonywania testów automatycznych, w oknie ZAP-a będą pojawiać się requesty HTTP do aplikacji pochodzące z twoich testowych skryptów automatycznych. Kiedy testy zakończą się, zaznacz w ZAP-ie cel i wybierz “Atak -> Aktywne Skanowanie” (możesz wcześniej użyć Atak -> Spider, jeżeli chcesz odnaleźć pozostałe obszary aplikacji, nie uwzględnione w trakcie trwania testów automatycznych).

Uruchomienie ataku OWASP ZAP

Uruchomienie automatycznego skanu w OWASP ZAP

Kiedy skaner wbudowany w ZAP-a zakończy pracę, otrzymasz raport z listą odnalezionych podatności. W szczegółach każdej z nich znajdziesz przykład (request i response), dzięki któremu będziesz w stanie odtworzyć problem manualnie, a także oszacowanie poziomu ryzyka, szczegółowy opis błędu oraz przede wszystkim rekomendacje, które pomogą programistom usunąć przyczynę problemu. Często nadają się one do przeklejenia 1:1 do Twojego raportu.

Zaprezentowane w artykule podejście jest tylko w połowie automatyczne. Dla fanów (pełnej) automatyzacji i Continous Integration, polecamy przejście pod adres http://localhost:8080/UI (gdy ZAP jest włączony), a znajdziecie tam informacje o RESTowym API, dzięki któremu doprowadzicie do tego, że cała “magia” będzie działa się bez udziału człowieka.

Pamiętaj o ograniczeniach

Automatyczne skanery bezpieczeństwa, takie jak OWASP ZAP, Burp Suite, Acunetix itp, na chwilę obecną nie są w stanie zastąpić w 100% testerów manualnych, którzy aplikację badają mając pełne wyobrażenie o jej przeznaczeniu, kontekście oraz modelu ról i uprawnień. Choć skanery całkiem dobrze (i szybciej niż ludzie!) radzą sobie podczas wykrywania podatności typu XSS i SQL Injection, to mają kilka istotnych ograniczeń:

  • nie rozumieją kontekstu testowanej aplikacji i jej modelu biznesowego, przez co nie odnajdą tzw. błędów logiki biznesowej,
  • nie mają wyobrażenia co do modelu ról i uprawnień i nie będą w stanie określić, czy dostęp do jakiegoś zasobu na danym koncie jest dopuszczalny (tzw. błędy eskalacji uprawnień pionowych i poziomych),
  • przy braku odpowiedniej konfiguracji, mogą się zapętlić lub pominąć istotne obszary aplikacji (np. te dostępne tylko po wysłaniu formularza chronionego captchą),
  • zgłaszają błędy, które w rzeczywistości nie są błędami (tzw. false-positives).

Nie oznacza to jednak, że powinniśmy ze skanerów rezygnować. Trzeba po prostu znać ich słabe strony i wiedzieć do czego (i kiedy) można ich użyć. Niewątpliwym plusem skanerów, jest to, że ich użycie nie wymaga od nas wielkiego zaangażowania oraz praktycznie nic nas nie kosztuje (chyba, że używasz skanerów płatnych ;). Jeżeli więc w Twoim projekcie nie są wykonywane profesjonalne, manualne testy bezpieczeństwa bo budżet na tego typu wydatki jest ograniczony, to użycie skanera automatycznego wydaje się być rozsądnym kompromisem. Zwłaszcza, że jeśli Twoja aplikacja będzie dostępna w internecie, to jest więcej niż pewne, że któryś z gimnazjalistów prędzej czy poźniej postanowi ją przeskanować skanerem automatycznym. Dlatego zawsze lepiej jest samodzielnie złowić kilka nawet podstawowych, niegroźnych błędów (tzw. low-hanging fruits) przy pomocy skanera, niż w ogóle nie mieć świadomości, że one istnieją.

Niniejszym wpisem rozpoczynamy cykl artykułów dedykowanych testerom QA, którzy chcieliby poszerzyć swoją wiedzę w zakresie testowania bezpieczeństwa aplikacji. W następnych odcinkach postaramy się zaprezentować kolejne rady, dzięki którym będziecie mogli skonfigurować obecnie używane przez Was narzędzia do wykonywania podstawowych testów bezpieczeństwa.

Przypominamy też, że tego typu wiedzę (w praktyce!) przekazujemy podczas naszych nowych szkoleń dedykowanych testerom QA. Co ważne, szkolenie zostało zaprojektowane tak, że nawet ci testerzy, którzy nie mają doświadczenia z narzędziami do automatyzacji testów, będą zadowoleni. Zapraszamy do rejestracji na najbliższy termin tego szkolenia, które odbędzie się w Krakowie 23-24 lutego 2017r.

P.S. Jeśli korzystasz w ramach wykonywanych przez siebie testów z jakiegoś skanera, daj znać, na jakie problemy natrafiłeś. Być może któryś z nich posłuży nam do stworzenia kolejnego artykułu.

Przeczytaj także:

4 komentarzy

Dodaj komentarz
  1. Już niedługo zagrożenie ze strony gimnazjalistów zniknie! :))

    Bardzo fajny artykuł.

    • Człowieku… rozjaśniłeś ten smutny, pechowy dzień. Cały pokój płakał ze śmiechu. :-D

      Pozdrawiam.

  2. Są jakies plany na te szkolenia dedykowane dla testerów w warszawie?

  3. Piszecie artykuł w którym chcecie podnieść świadomość QA testera odnośnie bezpieczeństwa, a potem w tekście wstawiacie linki “LMGTFY”? To zakładacie że QA nie znają Google? Czy poprostu chcecie komuś dopiec nieważne komu i czy sensownie?

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.