Praca programisty polega głównie na "klepaniu kodu". To, czy przygotowany przez nas kawałek tekstu odpowiada wymaganiom przełożonych, dość łatwo można sprawdzić - wystarczy zweryfikować, czy przedstawiona przez nich potrzeba biznesowa została zaspokojona. Jednak w świecie pełnym "złych ludzi" 😈 to nie wystarczy. Oprócz spełnienia wymagań biznesowych, aplikacje muszą zachowywać najwyższe standardy bezpieczeństwa. Jest to ważne, ponieważ systemy te składują wiele istotnych informacji, takich jak dane osobowe czy poufne dane, np. prywatne zdjęcia. Dzisiaj chciałbym poruszyć (bardzo delikatnie) ten problem i wskazać na ciekawe oraz proste w użyciu narzędzie do przeprowadzania testów penetracyjnych, to znaczy: weryfikowania bezpieczeństwa systemu.
Organizacja OWASP i proponowane przez nią narzędzie
Na początek zasygnalizuję, że istnieje fundacja OWASP, która zrzesza wiele organizacji zajmujących się bezpieczeństwem aplikacji. Na swojej stronie OWASP umieszcza wiele ciekawych informacji, porady, raporty na temat najczęściej występujących błędów (sławny w środowisku OWASP TOP 10), ale także odnośniki do ciekawych narzędzi. Jednym z tych narzędzi jest OWASP ZAP, który jest kombajnem pomagającym wykryć luki w aplikacji. Program można pobrać ze strony projektu.
Program jest prosty w instalacji, ale do poprawnego działania wymaga zainstalowania wirtualnej maszyny Javy. Po instalacji oraz uruchomieniu programu naszym oczom ukaże się interfejs programu:
Pierwsze kroki z programem
Przetestujemy narzędzie na domyślnych ustawieniach, dlatego w oknie powitalnym wybieramy opcję informującą o braku zapisu sesji ("No, I do not want to persist this session at this moment in time"). Następnie w zakładce Szybki start w polu z adresem URL do ataku wskazujemy lokalizację, pod którą znajduje się nasza aplikacja do przetestowania. Uwaga! Testy przeprowadzamy wyłącznie na serwerze testowym, nigdy na produkcyjnym, wystawionym na publicznym adresie IP. Opisywane narzędzie wygeneruje bardzo dużą ilość żądań do serwera, która może uruchomić jego mechanizmy obronne, np. odcięcie użytkownika od usługi. W moim przypadku testuję aplikację na hoście lokalnym (localhost), tak więc wpisuję ten adres w pole i naciskam przycisk Atak.
Po kilku minutach atak doszedł do skutku. Teraz klikając na zakładkę Zagrożenia (w dolnym panelu) możemy sprawdzić, jakie luki bezpieczeństwa zostały wykryte przez automat. W moim przypadku są to 3 typy zagrożeń:
Po kliknięciu w "strzałeczkę" zostanie wyświetlona lista żądań, które zawierały wymienioną lukę. Klikając na konkretne żądanie otrzymujemy więcej informacji oraz propozycję poprawki. Warto zwrócić uwagę na dwie informacje: stopień ryzyka (w moim przypadku jest na szczęście niskie) oraz informację o powiązanym numerze CWE (ang. Common Weakness Enumeration). Na stronie Common Weakness Enumeration możemy znaleźć więcej informacji na temat znalezionego zagrożenia.
Po naprawieniu znalezionych luk bezpieczeństwa możemy uruchomić ponownie skaner i zweryfikować, czy podatność dalej istnieje.
Kilka słów na koniec
Narzędzie opisane powyżej jest bardzo rozbudowane i sam nie jestem w stanie odkryć wszystkich jego możliwości. Niestety program jest dość toporny w samodzielnej konfiguracji, co dodatkowo utrudnia jego poznanie. Ale mimo to, jeżeli wykonanie szybkiego ataku sprawiło Ci dużą frajdę i ciekawość, zachęcam do dalszego eksperymentowania. Owocnego szukania bugów!
Komentarze
Ten wpis nie posiada komentarzy.
Dodaj komentarz
Pola oznaczone gwiazdką (*) są wymagane. Komentarze są wstępnie moderowane i mogą nie pojawić się na stronie.