Zapewnienie Bezpieczeństwa Na Etapie Quality Assurance - Security Bez Tabu

Zapewnienie Bezpieczeństwa Na Etapie Quality Assurance

Metody zapewnienia bezpieczeństwa na etapie Quality Assurance – Czyli jakie?

Jesteśmy w projekcie, w którym po pierwsze nie ma czasu na wykonanie testów bezpieczeństwa, po drugie klient nie dał nam budżetu na ich wykonanie, a po trzecie wyobraźmy sobie, że nie potrafimy ich przeprowadzić. Nie mamy specjalistycznej, technicznej wiedzy, aby wykonać takie testy bezpieczeństwa.

Czy w takiej sytuacji jako Quality Assurance, możemy zadbać o bezpieczeństwo?

Na to pytanie chciałbym dzisiaj odpowiedzieć. Ten materiał dedykowany jest specjalistom od zapewniania jakości, jednak wierzę, że inne osoby bezpośrednio związane z procesem wytwarzania oprogramowania także wyciągną z niego wartość.

Jak zapewnić podstawową jakość bezpieczeństwa?

To pytanie może wydawać się dość kontrowersyjne. Bo jeżeli myślimy o bezpieczeństwie, to nierzadko wydaje nam się, że są to górnolotne, bardzo zaawansowane techniki, takie „rocket science”.

Do głowy przychodzi nam sztuczna inteligencja, bardzo zaawansowane i specyficzne przypadki czy technikalia, które pływają na poziom bezpieczeństwa. I oczywiście możemy w taki sposób myśleć. Możemy w taki zaawansowany sposób dbać o bezpieczeństwo. Ale tak naprawdę na samym początku powinniśmy zejść dużo niżej, do fundamentów. Dopiero na tym poziomie powinniśmy myśleć o bezpieczeństwie. Bo jeżeli zapewnimy bezpieczeństwo na naprawdę wysokim, zaawansowanym poziomie, ale zapomnimy o fundamentach, to coś się może stać.

Odpowiadając teraz na pytanie: „jak zapewnić podstawową jakość bezpieczeństwa?”, odpowiedź jest prosta. Porozmawiajmy z zespołem oraz klientem i zadajmy pytania. Pod każdym pytaniem znajdują się przykładowe sytuacje czy dobre praktyki.

Czy dbamy o poufność przesyłanych plików/dokumentów?

  • dostęp do dokumentów ma tylko autor i ustalone osoby
  • edycja dokumentów jest możliwa tylko przez autora
  • pliki są przechowywane na serwerze w zabezpieczony sposób

Przykład

Jakieś dwa lata temu byłem w projekcie, który dedykowany był dla pracowników pewnej sieci restauracji. Jako kelner, kucharz, księgowy czy członek zarządu tej restauracji, dostałem tam dostęp i mogłem przesłać pewne pliki. Pliki dość kontrowersyjne, ponieważ były tam skany dowodów osobistych, paszportów czy nawet skan umowy o pracę. I niestety ja, jako użytkownik, miałem do tego dostęp – zarówno do swoich plików (co jest zrozumiałe), ale również do plików przesłanych przez inne osoby (co już takie zrozumiałe nie jest). Dzięki temu mogłem zweryfikować dowód osobisty mojej koleżanki czy nawet umowę o pracę jakiegoś kierownika, czy szefa. Mogłem zobaczyć również, ile taka osoba zarabia, nie wspominając już o aktualnych chorobach czy wynikach badań, bo i takie dane były tam dostępne. Czy w takiej sytuacji można mówić o zachowaniu poufności plików przesłanych przez użytkownika? Niekoniecznie.

Czy dbamy o prywatność użytkowników?

  • nie wskazujemy, że dany adres e-mail/użytkownik korzysta z  serwisu
  • korzystamy z  certyfikowanych usług
  • nie przechowujemy jawnie haseł
  • logujemy tylko wymagane informacje, bez danych prywatnych

I tu również podam przykład ze swojego życia zawodowego. Niestety nadal dość często się z tym spotykam. Wyobraź sobie bardzo kontrowersyjny serwis po jednej stronie oraz popularną osobę po drugiej. Zostawiam to Twojej wyobraźni. Teraz ja wchodzę do tego serwisu, klikam opcję „przypomnij hasło”, pojawia się formularz – muszę podać adres mailowy. Podaję go i pojawia się komunikat „nie znaleziono adresu w bazie”. To oznacza, że ja nie korzystam z tego serwisu. No i to jest prawda, ja nie zakładałem tam nigdy konta.

Teraz podaję adres tej znanej osoby. Pojawia się inny tekst walidacji: „na podany adres wysłano link z  resetem hasła”. To oznacza, że ta osoba korzysta z tego serwisu. Po czym wiem, że ten adres należy do tej osoby? Jeżeli mamy adres mailowy w stylu pseudonim@gmail.com, to oczywiście nie jestem w stanie w prosty sposób zidentyfikować konkretnej osoby. Jeżeli jednak mamy adres prywatny lub firmowy, na przykład imię.nazwisko@domenafirmowa, bądź kontakt@imięnazwisko.pl, sytuacja jest już inna – jestem w stanie bezpośrednio powiązać tego maila z konkretną osobą. W tym przypadku możemy już mówić o danych osobowych.

No i teraz, jeżeli taka znana persona użyła swojego służbowego albo prywatnego maila do tego bardzo kontrowersyjnego serwisu, to jestem w stanie powiązać ten serwis oraz maila z tą jedną osobą. Jeżeli taka informacja wycieknie, dana osoba może mieć w przyszłości jakieś problemy, chociażby naruszające jej wizerunek. Czy w takiej sytuacji możemy mówić, że zadbaliśmy o prywatność użytkowników? Niekoniecznie.

Jak do tego nie dopuścić? Przede wszystkim sprawdźmy teksty walidacji – nie powinny one wskazywać na fakt istnienia maila w bazie. Im bardziej uniwersalne treści, tym lepiej.

Przykład

„Jeżeli podałeś poprawnego maila, otrzymasz link z resetem hasła”. Sytuacja dotyczy nie tylko funkcji resetu hasła, ale również logowania czy rejestracji. Ten drugi przypadek może być dość specyficzny – najprostszym sposobem jest akceptacja wszystkich adresów, a dopiero później przesłanie odpowiedniego maila z linkiem do aktywacji konta (jeżeli konto nie istnieje) lub linkiem do resetu hasła (jeżeli konto istnieje i ktoś próbował się zarejestrować). Taka informacja jest również cenna dla samego użytkownika, bo jeśli to jest bardzo krytyczny serwis, np. bankowy, to użytkownik wówczas wie, że ktoś próbował wykorzystać jego dane, na przykład do tego, aby spróbować się zalogować czy aktywować aplikację mobilną.

Czy dbamy o bezpieczeństwo użytkowników?

Zdaję sobie oczywiście sprawę, że to bardzo ogólne pytanie. Jeżeli zadamy je w zespole, na pewno otrzymamy odpowiedź: ale o co ci chodzi? Zatem troszkę szerzej, czy możemy stwierdzić, że:

  • Mamy przemyślaną politykę haseł – to znaczy taką, która jest zgodna z  dobrymi praktykami. Aktualnie dobrym hasłem jest hasło długie, ale wcale nie musi być skomplikowane. Jak podaje CERT, lepszym hasłem będzie „wlazłKostekNaMostek”, niż hasło krótkie i zapchane znakami specjalnymi czy cyframi.

Przykład

Pytanie o przemyślaną politykę haseł oznacza również to, czy nie ograniczamy użytkownika w używaniu znaków specjalnych, cyfr, ale także spacji, znaków diakrytycznych (lub innych znaków lokalnych, np. umlaut) bądź emotikon. Ogólnie w haśle powinniśmy dopuszczać wszystkie drukowalne znaki unicode. Jeżeli tego nie robimy, oznacza to, że ograniczamy użytkownika, a to nie jest zgodne z  dobrymi praktykami polityki haseł.

  • Umożliwiamy dodatkowe zabezpieczenia (2FA, U2F)
  • Uświadamiamy użytkowników o bezpiecznym korzystaniu z usług czy hasła – miejsce, w którym użytkownik wprowadza swoje nowe hasło, jest miejscem idealnym do tego, żeby nauczyć go dobrych praktyk oraz zwiększyć jego świadomość. Mamy tam miejsca na tooltipy, walidację, tekst. Możemy zatem wskazać użytkownikowi: „Dzisiaj dobrymi praktykami jest to, aby ustawić hasło długie. Możesz skorzystać z menadżera haseł”. Warto informować użytkownika o tym, nie każdy jest bowiem tego świadomy.
  • Wiemy jakich informacji potrzebujemy od użytkowników (nie agregujemy nadmiarowych informacji)

Przykład

Tutaj cofnę się do tego przykładu z  serwisem dla pewnej sieci restauracji. Nie do końca wiem, dlaczego jako użytkownik, pracownik tej restauracji, musiałem zostawić tam skan dowodu osobistego, paszportu, danych lekarskich czy nawet umowę o pracę. Dla mnie bezpieczniejszą metodą było przesyłanie tych dokumentów bezpośrednio na maila, ograniczając się wyłącznie do osób zainteresowanych tematem, czyli kierownika, księgowości. Trzymanie takich danych gdzieś na serwerze, o którym nic nie wiemy (również w kontekście zabezpieczeń, szyfrowania) nie jest dobrym pomysłem – bo co, jeżeli te dane za miesiąc wyciekną? Czy ktoś da mi gwarancję, że nikt nie weźmie kredytu na moje dane? Dla mnie osobiście jest to nadmiar informacji, który ten serwis agregował. Zatem warto zastanowić się, czy tego wszystkiego potrzebujemy.

Co z aplikacjami mobilnymi?

Do tej pory mówiliśmy o aplikacjach webowych. W aplikacjach mobilnych większość tych tematów się powtórzy, np. polityka haseł, czy agregacja informacji. Ale aplikacje mobilne mają to do siebie, że mają kilka tematów, o które warto dodatkowo zadbać.

  • Ekran podglądu kart nie generuje podglądu wrażliwych widoków – jeżeli otwieram aplikację i przechodzę do podglądu otwartych okien, to chciałbym żeby aplikacja, która jest krytyczna, miała jakiś placeholder albo przynajmniej białe tło. Cokolwiek, co ukryje wrażliwe dane (saldo konta, wyniki badań, korespondencja).
  • Zrzuty ekranu wrażliwych miejsc są wyłączone – najłatwiej jest myśleć o bezpieczeństwie wyobrażając sobie pewne sytuacje. Więc wyobraźmy sobie, że na telefonie mam złośliwe oprogramowanie, które w tle co sekundę robi zrzuty ekranu i wysyła je na jakiś serwer. No i teraz wchodząc na konto bankowe, nie chciałbym aby moje saldo czy historia operacji znalazły się na tych zrzutach. Podobnie w przypadku aplikacji związanych z medycyną (wyniki badań), czy danymi osobowymi (pesel, dowód osobisty, rezerwacje hoteli, korespondencja).

    Dlatego warto przy takich krytycznych aplikacjach, a przynajmniej w krytycznych miejscach, zadbać o to, aby zablokować możliwość wykonywania zrzutu ekranu.
  • Aplikacja wymaga minimalnych zestawów uprawnień – czy nie wymagamy zbyt dużo uprawnień podczas uruchomienia czy korzystania z aplikacji? Bo jeżeli naszym projektem jest kalkulator, to nie wyobrażam sobie od użytkownika, na przykład, uprawnień do aparatu. No chyba że mamy funkcję obliczania równań napisanych na kartce papieru. ?
  • W aplikacji jest łatwy dostęp do dokumentów opisujących proces przetwarzania danych – to chyba dodatkowego komentarza nie wymaga. Mamy obowiązek informowania użytkowników o przetwarzaniu ich danych, ale również te regulaminy i zasady powinny być łatwo dostępne.

Czy dbamy o proces bezpieczeństwa w zespole/projekcie?

Sprecyzowany proces obsługi incydentów

Sprecyzowany proces obsługi incydentów – co to znaczy? Czy na przykład mamy plik security.txt, gdzie użytkownik może wejść i zobaczyć: „słuchaj, jeżeli spotkałeś się z jakimś wyciekiem danych z naszego portalu, koniecznie nam to zgłoś. Jeżeli znalazłeś jakąś lukę bezpieczeństwa, zgłoś to nam pod tym adresem mailowym czy numerem telefonu”.

Ponadto, jeżeli otrzymamy już takie zgłoszenie, czy wiemy co z tym zrobić? Czy mamy osobę, która przyjmie to zgłoszenie i wykona odpowiednie kroki?

Code review z uwzględnieniem dobrych praktyk

  • czy osoby wykonujące code review myślą o bezpieczeństwie oraz o dobrych praktykach związanych z tym tematem?
  • czy spoglądają na wersje frameworków bibliotek?
  • wersje są stale aktualizowane?

Co więcej, czy mamy już określony proces aktualizacji, gdy wyjdziemy z naszym projektem na produkcję? Bo często jest tak, że do momentu gdy wytwarzamy oprogramowanie, pilnujemy jeszcze tych aktualizacji. Natomiast gdy jesteśmy już na produkcji, może się zdarzyć, że pomijamy temat dalszych aktualizacji. Jeżeli nie będziemy tego robić, narażamy projekt na kolejne luki bezpieczeństwa czy podatności, które będą z czasem znalezione. To jest również dobry temat, aby uświadamiać klienta w tych kwestiach.

Zaktualizowana i gotowa do użycia dokumentacja

  • dokumentacja, w której są nie tylko kwestie techniczne związane z organizacją, ale też te związane z bezpieczeństwem.
  • czy te informacje są odpowiednio przechowywane?

W ramach tego pytania

  • czy dbamy o proces bezpieczeństwa w zespole/projekcie?

Monitorowanie i logowanie

  • czy mamy zaimplementowane rozwiązanie, które monitoruje i wyklucza na przykład próby pewnych ataków (np. brute force na ekranie logowania)?

Jeżeli jako użytkownik mogę próbować kilkadziesiąt czy kilkaset razy wpisać hasło do mojego/czyjegoś konta, to znaczy że coś jest nie tak – kiedyś mi się w końcu uda, prawda?

Warto tu również wspomnieć o dodatkowych zabezpieczeniach przed takimi akcjami, jak ratelimiting, captcha czy inne tego typu rozwiązania.

Dobry sprawdzony backup, regularnie testowany

  • czy mamy kopię zapasową, czy nam się wydaje, że ją mamy?
  • co więcej, czy regularnie testujemy nasz backup? Bo co z tego, że dzisiaj zrobiłem kopię zapasową, jutro uda mi się ją przywrócić, ale po tygodniu coś się stanie i już jej nie przywrócę?

I kolejna sprawa – wchodzimy na produkcję, działamy tam już kilka miesięcy, zbieramy dane użytkowników wymagane do wykonania jakiejś usługi. Robimy kopię zapasową. I teraz przychodzi klient i powołując się na pewne klauzule, mówi, że chciałby zrezygnować z przetwarzania danych. Prosi o usunięcie wszystkich jego informacji. Usuwamy więc te dane z  serwerów i dzień później jest jakaś awaria, przywracamy kopię sprzed tygodnia. Czy w takiej sytuacji przywrócimy również dane wspomnianego klienta? Czy kasując czyjeś dane, wykonujemy te akcje również w kopiach zapasowych? Niestety często okazuje się, że niekoniecznie.

Web Application Firewall

  • czy mamy takie rozwiązanie?
  • jakiego typu filtry mamy ustawione?
  • na co zwracamy uwagę?
  • czy jest to aktualizowane?

Automatyczne skany podatności

Zdaję sobie sprawę, że takie skany nigdy nie zastąpią testów bezpieczeństwa. Ale są dość istotne, ponieważ dobrze skonfigurowane, podniosą poziom zabezpieczeń.

Podsumowanie zadawania pytań

Podsumowując to zadawanie pytań, jeżeli my jako specjaliści od zapewniania jakości chcemy zadbać o to bezpieczeństwo, powinniśmy zadawać pytania. Po prostu rozmawiać, zwiększać świadomość zarówno w zespole jak i rozmawiając z klientem. Co więcej, możemy także spróbować wdrożyć pewne kwestie, tematy bezpieczeństwa do user stories, czyli wprowadzić taką historyjkę użytkownika, gdzie np. jako użytkownik nie mogę mieć podglądu do faktur innych użytkowników. Albo jako użytkownik nie mogę wykonywać akcji przeznaczonych dla konta administratora itd.

Dzięki temu z  czasem będziemy już mimowolnie oraz podświadomie sprawdzać tego typu kwestie i nie będzie nam to zajmowało dużo czasu. Dodatkowo pomoże nam to podczas pisania raportów czy wykonywania regresji. Tutaj również możemy porozmawiać z Project Managerem i poprosić go o dodatkowy dzień na to, aby w tym ostatnim dniu skupić się wyłącznie na tematach bezpieczeństwa. Powyższe tematy mogą Ci w tym pomóc.

Jak widzisz, warto dbać o to bezpieczeństwo i tak jak można już tutaj zauważyć, nie wymaga to ogromnych nakładów finansowych, a czasami nawet dużej ilości czasu. Zwłaszcza, jeżeli zadamy konkretne pytanie, takie bardzo ogólne, rozwinie się z tego jakaś dyskusja i wspólnie z zespołem wyciągniemy wnioski.

Nagłówki bezpieczeństwa

Do tej pory rozmawialiśmy o tym, w jaki sposób zapewnić bezpieczeństwo. To znaczy jak wdrożyć pewne elementy, pewne standardy zwiększające poziom bezpieczeństwa. Musimy wiedzieć, że część takich zabezpieczeń możemy przerzucić na przeglądarkę. Powiedzieć przeglądarce wprost: „słuchaj, z mojego serwisu będą korzystać użytkownicy. I teraz proszę cię przeglądarko, ochroń ich, zapewnij im jakiś poziom bezpieczeństwa. Zabezpiecz ich, na przykład, przed wykonywaniem złośliwych skryptów. Wymuś na nich korzystanie z wersji HTTPS. Ochroń ich przed xssem czy atakiem typu Clickjacking”. Służą do tego nagłówki bezpieczeństwa.

W tym temacie nie będę się rozwodził. Nie chcę tutaj żadnej teorii, nie chcę też opowiadać o sposobach implementacji – wszystko to znajdziesz w odpowiednich źródłach i dokumentacjach. Napiszę tylko krótko o sprawdzaniu tych nagłówków.

Służą do tego dwie strony. Ja bardzo rekomenduję https://observatory.mozilla.org/, gdzie wystarczy wejść na stronę i podać adres naszego serwisu. W odpowiedzi dostaniemy informację, jakie nagłówki są wdrożone, jakich nagłówków brakuje, a nawet informacje związane z  tym, co poszło nie tak.

Można skorzystać również z drugiej witryny, tj. https://securityheaders.com/. O ile ta pierwsza strona wykazuje nieco bardziej szczegółowe wyniki, ta druga jest czytelniejsza.

Nagłówki bezpieczeństwa można sprawdzić także z  poziomu konsoli developerskiej, analizując nagłówki przesyłane w requestach.

Podsumowanie

  • Bezpieczeństwo warto zacząć od zadawania pytań i rozmów
  • Jeżeli nie masz doświadczenia, pytania powinny być ogólne
  • Nie sugeruj rozwiązań, których nie jesteś pewny/pewna
  • Część zabezpieczeń przerzuć na przeglądarkę
  • Pamiętaj o zwiększaniu świadomości na tematy cyberbezpieczeństwa

Jako QA jesteśmy w stanie wpłynąć na bezpieczeństwo. Jeżeli nie mamy czasu na wykonanie testów bezpieczeństwa, jeżeli nie mamy na nie budżetu, a nawet specjalistycznej wiedzy, aby wykonać takie testy, nadal jesteśmy w stanie wpłynąć na to bezpieczeństwo. W jaki sposób? Zadając pytania, rozmawiając z zespołem, zwiększając świadomość na tego typu tematy.

Pamiętajmy też o tym, że część zabezpieczeń możemy przerzucić na przeglądarkę. Miejmy także świadomość, że temat bezpieczeństwa jest tematem bardzo żywym. Wiele się tutaj dzieje, wiele się zmienia i to naprawdę szybko. Warto zatem być na bieżąco, czytać i interesować się tematem.

O Autorze

Adam Gola

Security Specialist & Quality Assurance. Założyciel serwisu https://szkoleniedlaqa.pl .

Dziękujemy autorowi za to, że zechciał podzielić się swoją wiedzą i doświadczeniem na łamach SecurityBezTabu.pl