Testowanie bezpieczeństwa Jak to się robi? Wojciech Dworakowski

> 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

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

Po co testować bezpieczeństwo?

Trochę statystyki Verizon 2012 Data Breach Investigations Report

Z naszego doświadczenia Ponad 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

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

Przykład: Aplikacja finansowa Aplikacja 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

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

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

Przykłady defektów i sposoby ich wykrywania

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

Przykład: Brak kontroli dostępu do danych http://moj.bank/accountHistory?accountNr=1234 zmienienie accountNr na „cudzy” identyfikator Skutek: podgląd lub modyfikacja cudzych danych

Testowanie: Kontrola dostępu do danych Niby 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, …)

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

Testowanie: Doklejenie kodu intruza SQL 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

Błędy logiczne Przykłady: Autoryzacja transakcji kodem SMS Brak 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

Trzeba objąć całe spektrum potencjalnych problemów W 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

Narzędzia Głowa ;-) Local proxy Przechwytywanie żą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 ;-)

Metody weryfikacji bezpieczeństwa aplikacji Test 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)

Testy funkcjonalne vs Testy bezpieczeństwa Symulacja 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

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

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)?

W idealnym świecie 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

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

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

Testy bezpieczeństwa dla testerów funkcjonalnych Czy 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”

Testy bezpieczeństwa dla testerów funkcjonalnych Kontrola 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ę

Testy bezpieczeństwa dla testerów funkcjonalnych Defekty 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, …

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

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

Testy bezpieczeństwa to tylko element procesu QA Definiowanie 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

Dziękuję za uwagę http://www.securing.pl Wojciech Dworakowski e-mail: info@securing.pl Jontkowa Górka 14a 30-224 Kraków tel. (12) 4252575 fax. (12) 4252593 Wojciech Dworakowski wojciech.dworakowski@securing.pl tel. 506 184 550

Zapraszam Spotkania OWASP Poland Kraków, Warszawa, Poznań https://owasp.org/index.php/Poland http://www.meetup.com/OWASP-Poland/