Rickroll w repo i bomba w (niezbyt) głębokim ukryciu
Podatności aplikacji webowych miewają różną genezę. Mogą być niezawinione – błędom typu 0-day nie da się skutecznie zapobiec. Mogą być w pełni zawinione – gdy w trzeciej dekadzie XXI wieku programista pisze kod podatny na SQL injection. Mogą być też wynikiem roztargnienia lub nieuwagi – np. wtedy, gdy na świat wystawione zostanie repozytorium kodu, w którym przechowywana jest owa aplikacja. Nieuprawniony dostęp do takiego repozytorium może oznaczać przejęcie kontroli nad całą webaplikacją – gdy w kodzie źródłowym albo plikach konfiguracyjnych znajdziemy hasło do bazy danych, klucze prywatne do usług chmurowych albo plik tekstowy z hasłem administratora. Podobnie stanie się, gdy operator zapisze kopię bezpieczeństwa do pliku backup.zip zlokalizowanego w głównym katalogu witryny.
Ja postanowiłem zażartować sobie z osób, które szukają takich podatności.
Autorem artykułu jest Tomasz Zieliński, autor szkolenia z automatyzacji pobierania danych z internetu (scrapowanie.pl), w wolnych chwilach prowadzący bloga Informatyk Zakładowy (informatykzakladowy.pl). Za publikację nie otrzymaliśmy wynagrodzenia, ale otrzymamy świadczenie barterowe.
Trojański backup.zip, który wybucha
Z kopią bezpieczeństwa było łatwo – plik https://informatykzakladowy.pl/backup.zip to tak zwana ZIP-bomba. Jest to archiwum plików spreparowane w taki sposób, aby zawartość po rozpakowaniu zajmowała możliwie najwięcej miejsca. Skorzystałem z wariantu opisanego na stronie bamsoftware.com – choć sam plik ZIP ma niespełna 10 megabajtów, to do zapisania zdekompresowanej zawartości potrzeba 281 terabajtów. Dla porównania – typowy dysk twardy w domowym komputerze ma nie więcej niż dwa terabajty.
W dzisiejszych czasach ZIP-bomby są raczej [...]
#ARTYKUŁSPONSOROWANY #Śmieszne #Git #Repozytoria #Scraping #Scrapowanie #Wycieki
https://niebezpiecznik.pl/post/rickroll-w-repo-i-bomba-w-niezbyt-glebokim-ukryciu/