Testowanie bezpieczeństwa. Teoria

Testowanie bezpieczeństwa różni się od innych form testowania, w dwóch istotnych obszarach: 

1. Standardowe techniki wyboru wejściowych danych testowych mogą nie uwzględniać ważnych kwestii bezpieczeństwa.
2. Objawy problemów związanych z bezpieczeństwem bardzo się różnią od symptomów, wykrywanych w innych rodzajach testowania. 

W ramach testowania bezpieczeństwa dokonywana jest ocena podatności systemu na zagrożenia. Poprzez próby naruszenia bezpieczeństwa danego systemu, określone przez jego twórców, ekspert bezpieczeństwa stara się znaleźć możliwość, by dokonać operacji, które są niedozwolone. Poniższa lista zawiera przykładowe, potencjalne zagrożenia, które należy uwzględnić podczas testowania bezpieczeństwa: 

• Kopiowanie aplikacji lub danych bez upoważnienia. 
• Nieautoryzowany dostęp (np. możliwość wykonywania zadań, do których użytkownik nie ma uprawnień). Prawa użytkowników, zasady dostępu i uprawnienia są najważniejszymi elementami, sprawdzanymi podczas testowania. Takie informacje powinny być dostępne w specyfikacji systemu. 
• Oprogramowanie, którego zamierzonemu działaniu, towarzyszą niezamierzone skutki uboczne. Na przykład, działanie odtwarzacza plików multimedialnych, który poprawnie odtwarza pliki audio, ale zapisuje przy tym pliki w nieszyfrowanej pamięci tymczasowej, towarzyszy skutek uboczny, który może zostać wykorzystany przez cyberprzestępców. 
• Kod umieszczany na stronie internetowej, który może zostać uruchomiony przez kolejnych użytkowników (tzw. cross-site scripting XSS). 
• Przepełnienie bufora, które może być spowodowane wprowadzaniem w polu wejściowym, w interfejsie użytkownika, łańcuchów o długości większej niż możliwa do poprawnego obsłużenia w kodzie. Występowanie tego zjawiska może stanowić okazję do uruchomienia szkodliwego kodu. 
• Odmowa usługi, czyli sytuacja, gdy użytkownicy nie mogą nawiązać interakcji z aplikacją (przyczyną może być np. przeciążenie serwera WWW ustawicznie ponawianymi żądaniami). 
• Przechwycenie, naśladowanie lub modyfikowanie, a następnie przekierowanie informacji (np. transakcji kartą kredytową) przez stronę trzecią w taki sposób, że użytkownik pozostaje nieświadomy istnienia strony trzeciej (atak typu man in the middle). 
• Złamanie algorytmów szyfrujących używanych do ochrony wrażliwych danych. 
• Bomby logiczne (nazywane czasami „kukułczymi jajami”), które mogą zostać rozmyślnie umieszczone w kodzie i aktywowane jedynie w pewnych okolicznościach (np. konkretnego dnia). Po aktywacji, bomba logiczna może wykonać szkodliwe działania, takie jak usunięcie plików albo sformatowanie dysków. 

I wiele, wiele innych.

Podczas planowania testów bezpieczeństwa należy w szczególności zastanowić się nad następującymi zagadnieniami: 

• Weryfikacja bezpieczeństwa od wczesnych etapów wytwórczych - ponieważ problemy dotyczące zabezpieczeń mogą się pojawić w trakcie tworzenia architektury, projektowania oraz implementacji systemu, można zaplanować testy zabezpieczeń na poziomie testowania jednostkowego, integracyjnego i systemowego. Ze względu na zmienność zagrożeń, testy zabezpieczeń można także wykonywać regularnie, po wdrożeniu produkcyjnym systemu. 
• Działania inne niż atakowanie oprogramowania - strategie testów zaproponowane przez eksperta mogą obejmować przeglądy kodu i analizę statyczną z wykorzystaniem narzędzi weryfikacji zabezpieczeń. Narzędzia tego typu mogą być skutecznym środkiem wykrywania problemów związanych z bezpieczeństwem w architekturze, dokumentach projektowych i kodzie, które łatwo pominąć w trakcie testowania dynamicznego. 
• Koordynacja działań projektowych - ekspert bezpieczeństwa może zostać poproszony o zaprojektowanie i wykonanie pewnych typów „ataków” (patrz poniżej), które wymagają szczegółowego zaplanowania i skoordynowania działań z interesariuszami. Inne testy zabezpieczeń można wykonać we współpracy z programistami lub analitykami testowymi (np. testowanie praw użytkowników, zasad dostępu i uprawnień). W ramach planowania testów zabezpieczeń należy szczegółowo uwzględnić kwestie organizacyjne tego rodzaju. 
• Akceptacja działań - ekspert musi uzyskać wyraźne zezwolenie od przełożonych na wykonanie zaplanowanych testów zabezpieczeń. Wszelkie dodatkowe, niezaplanowane testy mogą zostać uznane za rzeczywiste ataki, a osoba wykonująca takie testy jest narażona na podjęcie wobec niej działań prawnych. W przypadku braku potwierdzenia planów i uzyskania akceptacji w formie pisemnej, wytłumaczenie typu „my tylko prowadzimy testy zabezpieczeń” może nie zabrzmieć zbyt przekonująco. 
• Zależność bezpieczeństwa od innych cech oprogramowania - należy zwrócić uwagę, czy udoskonalenia, których celem jest poprawa bezpieczeństwa systemu, mogą np. obniżyć jego wydajność. Po wprowadzeniu takich modyfikacji zalecane jest rozważenie konieczności wykonania testów wydajnościowych. 

Testy bezpieczeństwa można pogrupować według źródła pochodzenia określonego zagrożenia: 

• Związane z interfejsem użytkownika — nieautoryzowany dostęp i dane wejściowe wywołujące szkodliwe skutki. 
• Związane z systemem plików — dostęp do wrażliwych danych, przechowywanych w plikach lub repozytoriach. 
• Związane z systemem operacyjnym — przechowywanie poufnych informacji (np. haseł) w postaci niezaszyfrowanej w pamięci, której zawartość może zostać ujawniona po załamaniu systemu, wywołanym przez szkodliwe dane wejściowe. 
• Związane z zewnętrznym oprogramowaniem — interakcje, które mogą wystąpić między zewnętrznymi komponentami używanymi przez system. Takie problemy mogą pojawić się na poziomie sieci (np. przesłanie niepoprawnych pakietów lub komunikatów) lub na poziomie modułów oprogramowania (np. awaria modułu oprogramowania niezbędnego do działania systemu). 

Podczas projektowania testów zabezpieczeń można skorzystać z następującego podejścia: 

• Zbierz informacje oraz dane, które mogą okazać się przydatne podczas specyfikowania testów, np. nazwiska pracowników, adresy fizyczne, szczegółowe informacje o sieciach wewnętrznych, adresy IP, sygnatury używanego oprogramowania i sprzętu oraz wersje systemu operacyjnego. 
• Przeskanuj słabe punkty zabezpieczeń za pomocą ogólnie dostępnych narzędzi. Narzędzia tego rodzaju nie służą do podejmowania bezpośrednich ataków na system, ale do zidentyfikowania słabych punktów zabezpieczeń, które stanowią naruszenie zasad ochrony lub mogą takie naruszenie spowodować. Konkretne zagrożenia da się także zidentyfikować z wykorzystaniem list kontrolnych, takich jak listy opublikowane przez National Institute of Standards and Technology (NIST). 
• Korzystając ze zgromadzonych informacji, opracuj „plany ataków” (tj. plany działań zmierzających do naruszenia zasad ochrony konkretnego systemu). W planach ataków należy wyspecyfikować wykorzystanie różnych danych wejściowych, wprowadzanych za pośrednictwem różnych interfejsów (np. interfejsu użytkownika i systemu plików), tak aby możliwe było wykrycie najpoważniejszych usterek związanych z zabezpieczeniami. Różne „ataki”, opisane w szeregu publikacji o bezpieczeństwie, stanowią przydatny przegląd technik opracowanych specjalnie w celu testowania bezpieczeństwa. 

Wspomniane wcześniej narzędzia do analizy statycznej zawierają rozbudowany zestaw reguł związanych z zagrożeniami bezpieczeństwa, służących do weryfikowania różnych aspektów zachowania oprogramowania. Narzędzie jest w stanie, na przykład, wykryć problemy z przepełnieniem bufora, wynikające z braku sprawdzenia jego wielkości przed umieszczeniem w nim danych. Narzędzi do analizy statycznej można użyć także w przypadku kodu aplikacji internetowej, aby wykryć potencjalne zagrożenia związane ze wstrzykiwaniem kodu, obsługą plików cookie, osadzaniem kodu pochodzącego z innych witryn, manipulacją zasobami i wstrzykiwaniem kodu SQL.

Artykuł bazuje na sylabusie „Wersja 2012 Certyfikowany Tester. Sylabus dla poziomu zaawansowanego Techniczny Analityk Testowy”. Do największych zmian należą:

• zamiana pojęć ISTQB na pojęcia popularnonaukowe,
• usunięcie referencji wewnętrznych i zewnętrznych,
• dodanie lead,
• zmodyfikowanie niektórych określeń.