This is an old revision of the document!
File upload ranjivosti odnose se na napade koji se izvršavaju postavljanjem (uploadom) maliciozne datoteke na poslužitelj. Svaki korisnički unos treba biti pročišćen prije procesiranja. U slučaju kad se prima samo tekst, napadač može pokušati upisati neku malicioznu naredbu i tada se javljaju ranjivosti poput SQL injectiona ili SSTI-ja. Zadaća je sustava da prepozna pokušaj unosa naredbe i da spriječi njezino izvođenje.
Web aplikacije često dozvoljavaju i prijenos datoteka na poslužitelj (fotografija, dokumenata i slično). U tom slučaju napadač može manipulirati datotekom koju prenosi na poslužitelj i napraviti štetu. Najjednostavniji je slučaj u aplikacijama koje nemaju popis dozvoljenih ekstenzija, već prihvaćaju datoteke svih formata. Tada je moguće jednostavno objaviti .php, .py ili bilo koju datoteku koja se može izvršiti kao programski kôd. Uspješan prijenos takve datoteke nije uvijek dovoljan da bi se kôd izvršio, već je potrebno i da poslužitelj bude konfiguriran tako da zaista izvede taj kôd.
PRIMJER - Zadatak s Hacknite platforme - Posluživanje datoteka
Ivica je zaključio da je jedna od ključnih vještina koje treba vježbati rad s datotekama kroz web stranicu. Kako bi apsolvirao taj skup vještina, odlučio je napraviti vlastiti servis za posluživanje datoteka. Naravno, uvijek oprezni Ivica se dosjetio da treba spriječiti da korisnici servisa zloupotrebljavaju njegovu dobru volju i ograničene računalne resurse pa je zato strogo ograničio veličinu datoteka koje njegova web stranica prihvaća. Možeš li pogledati njegovu novu web stranicu i provjeriti je li trebao još što ograničiti? ô Flag je u formatu CTF2020[brojevi] http://chal.platforma.hacknite.hr:11012
Budući da u zadatku nije navededno, aplikacija vjerojatno ne provjerava ekstenzije datoteka koje se objavljuju. Pokušajmo za početak objaviti .php datoteku. Napravimo datoteku test.php datoteku i upišimo u nju:
<?php echo "Hello world!" ?>
Zatim odaberimo u navigaciji “Datoteke” i postavimo ju tamo. Vidimo da nam je uspjelo, no još treba provjeriti je li se kôd izvršio. Po uspješnom postavljanju datoteke, stranica nas obavještava gdje je datoteka postavljena. Ako pratimo tu poveznicu, vidjet ćemo sljedeće:
Dakle, kod se izvršio. Sad napišimo neku naredbu kojom ćemo dobiti flag.
Ako aplikacija nema provjeru naziva datoteke koja se postavlja, napadač može objaviti datoteku istog naziva kao neka datoteka kritična za rad sustava i na taj način ju prebrisati. U još ekstremnijem slučaju, napadač može u naziv datoteke ubaciti sekvencu za pomicanje po direktorijima (..) i na taj način objaviti datoteke na lokacije kojima ne bi smio imati pristup. Dobra je praksa da sustav sam dodijeli ime datoteci koja se objavljuje. Vrlo je važno imati i provjeru veličine datoteke koja se postavlja. Prevelika datoteka može izazvati tzv. Denial of service (DoS) napad koji izaziva preopterećenje sustava i onemogućuje njegov rad.
Iako gotovo sigurno ne postoji web stranica koja nema validaciju datoteka, često se dogodi da ona ne bude dobro provedena.
Ako sustav ima listu ekstenzija koje smatra opasnima, to nije uvijek dovoljna zaštita jer je uvijek moguće da se neki opasan format zaboravi dodati na listu. Bolja je opcija dozvoliti samo određene formate datoteka i to one koji su ključni za rad aplikacije, a sve ostale zabraniti. Doduše, nije ni to uvijek dovoljno. Na primjer, ako zabranimo .php datoteke, moguće je da netko pošalje .php5, .pHp datoteku ili čak da datoteka ima dvostruku ekstenziju (datoteka.php.jpg). Nekad je dovoljno nakon ekstenzije dodati točku, razmak ili nešto slično. Također, može se koristiti URL encoding. Datoteka se može nazvati “datoteka%2Ephp”. Preglednik će %2E interpretirati kao točku, dakle “%2Ephp” će biti “.php”. Uobičajena provjera ekstenzije neće ju detektirati jer programi za parsiranje imena datoteke redovito traže prvu pojavu točke i sve nakon nje interpretiraju kao ekstenziju. Program koji parsira ime datoteke neće prepoznati točku, dakle neće ni pronaći ekstenziju.
PRIMJER - Zadatak s Hacknite platforme - Posluživanje slika
Problem je i kad se provjera formata temelji isključivo na zaglavljima zahtjeva (primjerice Content-Type) koja se mogu jednostavno promijeniti koristeći neki alat za presretanje zahtjeva, primjerice Burp Suite. Trebalo bi još utvrditi i da sadržaj datoteke zaista odgovara tom formatu. Na primjer, ako aplikacija prima fotografiju, trebalo bi pokušati odrediti neke osobine koje imaju samo fotografije (dimenzija, rezolucija). Ako se pošalje neka skripta, njoj se te osobine ne mogu odrediti, dakle sustav može prepoznati da nije riječ o fotografiji i odbaciti ju. Naravno, važno je da se pritom datoteka ne otvara jer bi to moglo potaknuti izvršavanje koda.
Budući da je gotovo nemoguće pokriti sve nedostatke koje validacija može imati, potrebno je konfigurirati poslužitelj tako da se, ako do njega dođe izvršivi programski kôd, spriječi njegovo izvršavanje. Dodatna mjera zaštite je onemogućiti postavljanje datoteke prije nego što prođe sve provjere. Neki sustavi koriste odvojeno privremeno spremište (tzv. sandbox) u koji stave datoteku i od tamo ju provjeravaju. Nekad je praksa bila postaviti datoteku na poslužitelj i obrisati ju ako se ispostavi da je maliciozna, no pokazano je da je čak nekoliko milisekundi dovoljno da bi se pokrenulo izvršavanje koda.
PRIMJER - Zadatak s Hacknite platforme - Učitavanje slike.php (restrikcije na klijentskoj razini)