1 Testowanie bezpieczeństwaJak to się robi? Wojciech Dworakowski

2 > whoami SecuRing (od 2003)Testowanie i doradztwo dotyczące bezpieczeństwa aplikacji i systemów IT Badania dotyczące nowych metod ataku i obrony OWASP Poland Chapter Leader Propagowanie wiedzy związanej z bezpieczeństwem aplikacji

3 Agenda Czy testy bezpieczeństwa są potrzebne? Na czym polegają testy bezpieczeństwa? Wyzwania (zakres, czas, …) Czy część testów bezpieczeństwa może być wykonana przez testerów funkcjonalności? Podsumowanie

4 Po co testować bezpieczeństwo?

5 Trochę statystyki Verizon 2012 Data Breach Investigations Report

6 Z naszego doświadczeniaPonad 400 zbadanych systemów i aplikacji Średnio ok. 10 podatności na badany system W ponad 30% przypadków znajdujemy podatności o znaczeniu kluczowym

7 Przykład - Wheedle październik 2012 Nowy serwis aukcyjny

8 Przykład: Aplikacja finansowaAplikacja zamawiana w software house Testy bezpieczeństwa przed wdrożeniem Całkowity brak kontroli dostępu do danych Dostawca: Kontrola dostępu jest ale „nie włączona” Po „włączeniu” – znalezione kolejne przypadki Koszt: Opóźnienie, wizerunek, kary umowne

9 Rosnące koszty usuwania błędówUtrzymanie Dotyczy to również defektów bezpieczeństwa! Wdrażanie Wytwarzanie Projektowanie Definiowanie

10 Co zwiększa ryzyko? Time to market Złożoność systemówNowe zastosowania SaaS, IaaS, mobile, NFC, M2M … Nowe technologie jQuery, JSON, HTML5. … Time to market

11 Przykłady defektów i sposoby ich wykrywania

12 Brak kontroli dostępu do funkcjiTestowanie: Wywołaj funkcje z poziomu innego użytkownika Analiza macierzy uprawnień (dokumentacja?) Trzeba sprawdzić wszystkie przypadki FUNKCJA x ROLA Nie zawsze (rzadko?) w URL

13 Przykład: Brak kontroli dostępu do danych zmienienie accountNr na „cudzy” identyfikator Skutek: podgląd lub modyfikacja cudzych danych

14 Testowanie: Kontrola dostępu do danychNiby proste, ale: Trzeba odnaleźć wszystkie identyfikatory „globalne” ilość (  czas  pieniądze ) zależy od sposobu implementacji aplikacji Dla każdego z nich spróbować „cudzej” wartości Rzadko kiedy w URL (POST, JSON, XML, …)

15 Przykład: SQL injectionZalogowanie się do aplikacji bez znajomości hasła Pobranie dowolnych informacji z bazy danych zasilającej aplikację

16 Testowanie: Doklejenie kodu intruzaSQL injection, Cross-site scripting (XSS), command iniection, LDAP injection… Dla każdego parametru przekazywanego od klienta… …sprawdź czy da się zakłócić składnie Trzeba stosować wiele metod (fuzzing) Nie zawsze wynik jest jednoznaczny Da się zautomatyzować ale nie jest to łatwe Konieczność dostosowania narzędzia False positives

17 Błędy logiczne Przykłady: Autoryzacja transakcji kodem SMSBrak autoryzacji operacji zmiany nr telefonu Możliwość przeskoczenia autoryzacji Opis transakcji jest ustalany po stronie przeglądarki Przykład: Zlecenia stałe Ustawienie zlecenia co 0 dni Testowanie: Zależne od scenariusza

18 Trzeba objąć całe spektrum potencjalnych problemówW oparciu o analizę ryzyka (zagrożeń i potencjalnych skutków) Jeśli nie ma możliwości to stosuj standardy: OWASP Top 10 Lista 10 najczęstszych typów defektów bezpieczeństwa OWASP Application Security Verification Standard Rozbudowana lista kontrola do weryfikacji (lub definiowania) bezpieczeństwa aplikacji OWASP Testing Guide Przewodnik po metodach i narzędziach Top 10 ASVS L1 ASVS L2 ASVS L3

19 Narzędzia Głowa ;-) Local proxyPrzechwytywanie żądań i odpowiedzi HTTP(S) Możliwość zatrzymania i ręcznej modyfikacji Możliwość automatyzacji scenariuszy (oskryptowania) Fiddler, Burp Suite, WebScarab, ZAP, … Języki skryptowe Narzędzia automatyzujące Głowa ;-)

20

21

22

23 Metody weryfikacji bezpieczeństwa aplikacjiTest penetracyjny Empiryczny (dynamiczny) Blackbox / Greybox / Whitebox Przegląd kodu Nie zapominajmy o środowisku Testy penetracyjne środowiska sieciowo-serwerowego Przegląd konfiguracji Najlepiej w połaczeniu (whitebox)

24 Testy funkcjonalne vs Testy bezpieczeństwaSymulacja działań użytkownika Symulacja działań intruza Scenariusze użycia Scenariusze nadużyć (ataku) Wymaga analizy zagrożeń Opisane (lub intuicyjne) wymagania Z reguły brak zdefiniowanych wymagań (zwłaszcza niefunkcjonalnych) Poszukiwanie niewidocznej funkcjonalności Pozostawione defekty może znaleźć użytkownik Pozostawione defekty może znaleźć intruz Defekt w niszowej funkcjonalności z reguły nie jest bardzo istotny Defekt w dowolnym miejscu systemu może mieć ogromne skutki

25 Intruz vs Tester Testy bezpieczeństwa – wyzwaniaNieograniczony czas Wiele grup Duża motywacja Ograniczony czas Jeden zespół ?

26 Właściwe ustalenie zakresu Znaleziono N podatności ale… Czy znaleziono wszystkie istotne podatności? Czy obsłużono wszystkie istotne zagrożenia? Czy szukano tam gdzie trzeba? Czy test symulował realne zagrożenie (atak)?

27 W idealnym świecie Definiowanie Identyfikacja ryzykaDo kluczowych ryzyk są dobierane zabezpieczenia Zdefiniowanie założeń Projektowanie Założenia są weryfikowane w projekcie Wykonanie Testy jednostkowe zabezpieczeń i poprawności kodu (według przyjętych założeń) Wdrażanie Testy odbiorcze – w zakresie odpowiadającym przyjętym założeniom

28 Szara rzeczywistość Brak założeńDefiniowanie Identyfikacja ryzyka Do kluczowych ryzyk są dobierane zabezpieczenia Zdefiniowanie założeń Projektowanie Założenia są weryfikowane w projekcie Wykonanie Testy jednostkowe zabezpieczeń i poprawności kodu (według przyjętych założeń) Wdrażanie Testy odbiorcze – w zakresie odpowiadającym przyjętym założeniom Brak założeń Brak kwestii niefunkcjonalnych (SQLi, XSS, CSRF, kontrola dostępu, logika, …) Brak uwzględnienia realnych scenariuszy ataku

29 Zakres testów w oparciu o ryzykoPlanowanie Wykonanie Raport Identyfikacja ryzyka Ranking ryzyk Scenariusze ataku Najpierw najistotniejsze Ścisła współpraca Greybox Spis podatności i wykonanych testów Realne zalecenia

30 Testy bezpieczeństwa dla testerów funkcjonalnychCzy testy bezpieczeństwa mogą być wykonywane przez zespół testujący funkcjonalność? TAK …ale: Przy okazji testowania funkcjonalności W podstawowym zakresie Po wstępnym przeszkoleniu Cel: Wykrycie „nisko wiszących owoców”

31 Testy bezpieczeństwa dla testerów funkcjonalnychKontrola dostępu do funkcji BASIC: Powtarzanie URL-i na różnych rolach ADVANCED: Powtarzanie (sekwencji) wywołań POST, jQuery, … Kontrola dostępu do danych BASIC: Manipulacja identyfikatorami danych w URL ADVANCED: w POST, jQuery, Cookies, Headers, … SQL-injection Fuzzing + wykrywanie potencjalnych symptomów Do zweryfikowania przez specjalistę

32 Testy bezpieczeństwa dla testerów funkcjonalnychDefekty konfiguracji środowiska Podstawowe (np. listing katalogów, wyświetlanie wyjątków, …) Stosowanie skanerów automatycznych Np. poszukiwanie „ukrytej funkcjonalności” Interpretacja wyników Defekty uwierzytelniania i zarządzania sesją Np. brak wygasania sesji, ataki brute-force, odzyskiwanie hasła, …

33 Podsumowanie Nie ma bezpieczeństwa 100% …ale trzeba ograniczać ryzyko do ŚWIADOMIE zaakceptowanego poziomu

34 Podsumowanie Bezpieczeństwo jest elementem jakości, więc też trzeba je testować Testy bezpieczeństwa wymagają innego podejścia szczegółowego zaplanowania wiedzy specjalistycznej doświadczenia Ale część testów może być wykonana przez testerów funkcjonalnych

35 Testy bezpieczeństwa to tylko element procesu QADefiniowanie Identyfikacja ryzyka Do kluczowych ryzyk są dobierane zabezpieczenia Zdefiniowanie założeń Projektowanie Założenia są weryfikowane w projekcie Wykonanie Testy jednost kowe zabezp ieczeń i popra wności kodu (wedłu g przyjęt ych założe ń) Wdrażanie Testy odbior cze – w zakresi e odpowi adając ym przyjęt ym założe niom

36 Dziękuję za uwagę http://www.securing.pl Wojciech Dworakowski Jontkowa Górka 14a Kraków tel. (12) fax. (12) Wojciech Dworakowski tel

37 Zapraszam Spotkania OWASP Poland Kraków, Warszawa, Poznań https://owasp.org/index.php/Poland