Testowanie bezpieczestwa Jak to si robi Wojciech Dworakowski

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

> whoami Secu. Ring (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 2

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 3

Po co testować bezpieczeństwo?

Trochę statystyki Verizon 2012 Data Breach Investigations Report 5

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 6

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

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 8

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

Co zwiększa ryzyko? Złożoność systemów Nowe zastosowania Saa. S, Iaa. S, mobile, NFC, M 2 M … Nowe technologie j. Query, JSON, HTML 5. … Time to market 10

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 12

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

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, …) 14

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

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 16

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 17

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 Top 10 ASVS L 1 § OWASP Application Security Verification Standard ASVS L 2 – Rozbudowana lista kontrola do weryfikacji (lub definiowania) bezpieczeństwa aplikacji ASVS L 3 § OWASP Testing Guide – Przewodnik po metodach i narzędziach 18

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

20

21

22

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

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 24

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

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

W idealnym świecie Definiowanie • Identyfikacja ryzyka • Do kluczowych ryzyk są dobierane zabezpieczenia • Zdefiniowanie założeń Wykonanie Projektowanie • Założenia są weryfikowane w projekcie • 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 27

Szara rzeczywistość Definiowanie • Identyfikacja ryzyka • Do kluczowych ryzyk są dobierane zabezpieczenia • Zdefiniowanie założeń Wykonanie Projektowanie • Założenia są weryfikowane w projekcie • 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 28

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

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” 30

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, j. Query, … Kontrola dostępu do danych § BASIC: Manipulacja identyfikatorami danych w URL § ADVANCED: w POST, j. Query, Cookies, Headers, … SQL-injection § Fuzzing + wykrywanie potencjalnych symptomów § Do zweryfikowania przez specjalistę 31

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, … 32

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

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 34

Testy bezpieczeństwa to tylko element procesu QA Definiowanie • Identyfikacja ryzyka • Do kluczowych ryzyk są dobierane zabezpieczeni a • Zdefiniowanie założeń Wykonanie Wdrażanie Projektowanie • Założenia są weryfikowane w projekcie • Testy jednostkowe zabezpieczeń i poprawności kodu (według przyjętych założeń) • Testy odbiorcze – w zakresie odpowiadając ym przyjętym założeniom 35

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

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