Phenquestions
U ovom ćete članku od aplikacije dobiti potrebne podatke kako biste znali što napadačko mjesto treba učiniti za slanje valjanih zahtjeva na ranjivi poslužitelj. Zatim ćete stvoriti stranicu koja simulira legitimne zahtjeve i zavarava korisnika da posjeti tu stranicu dok je ovjeren. Također ćete napraviti nekoliko ponavljanja osnovnog dokaza koncepta kako bi izgledao više poput napada iz stvarnog svijeta, gdje ga žrtva ne primjećuje. Datoteku koda za ovaj članak možete pronaći na autorskom githubu.
Spremiti se
Za ovaj članak trebat će vam važeći korisnički račun u BodgeItu. Ovaj članak koristi [e-pošta zaštićena] kao žrtva:
Kako to učiniti…
Prvo morate analizirati zahtjev na koji želite prisiliti žrtvu. Da biste to učinili, potreban vam je Burp Suite ili drugi proxy konfiguriran u pregledniku:
- Prijavite se na BodgeIt kao bilo koji korisnik i kliknite korisničko ime da biste otišli na profil.
- Promijenite lozinku. Pogledajte kako zahtjev izgleda u proxyju:
Dakle, to je
OBJAVIzahtjev zahttp: // 192.168.56.11 / bodgeit / lozinka.jsp,a u tijelu ima samo lozinku i njezinu potvrdu. - Pokušajte napraviti vrlo jednostavnu HTML stranicu koja replicira ovaj zahtjev. Stvorite datoteku (nazovite je
csrf-change-password.html) sa sljedećim sadržajima:
- Sada učitajte ovu datoteku u isti preglednik kao i vaša prijavljena sesija:
- Kliknite na Pošalji i bit ćete preusmjereni na stranicu profila korisnika. Reći će vam da je lozinka uspješno ažurirana.
- Iako ovo dokazuje poantu, vanjska stranica (ili lokalna HTML stranica kao u ovom slučaju) može izvršiti zahtjev za promjenom lozinke na aplikaciji. Još uvijek je malo vjerojatno da će korisnik kliknuti na podnijeti Možete ga automatizirati i sakriti polja za unos tako da je zlonamjerni sadržaj skriven. Sada napravite novu stranicu na temelju prethodne; nazovi to
csrf-change-password-scripted.html:Potpuno bezazlena stranica
Možete vjerovati ovoj stranici.
Ništa loše neće se dogoditi vama ni vašem BodgeIt računu.
Ovaj put obrazac ima parametar ID i na stranici se nalazi skripta koja će poslati svoj sadržaj kad se stranica u potpunosti učita.
- Ako ovu stranicu učitate u isti preglednik u kojem je pokrenuta BodgeIt sesija, ona će automatski poslati zahtjev i nakon toga će se prikazati stranica korisničkog profila. Na sljedećem snimku zaslona preglednika Program za ispravljanje pogrešakapostavite točku prijelaza neposredno prije postavljanja zahtjeva:
- Ovaj posljednji pokušaj izgleda bolje iz perspektive napadača. Trebate samo da žrtva učita stranicu i zahtjev će se automatski poslati, ali tada će žrtva vidjeti Vaša lozinka je promijenjenaporuku, a to će zasigurno podići upozorenje.
- Napadačku stranicu možete dodatno poboljšati tako što ćete odgovor učitati u nevidljivi okvir unutar iste stranice. Postoji mnogo načina za to; brzi i prljavi je postaviti veličinu 0 za okvir. Vaša bi datoteka izgledala ovako:
Potpuno bezazlena stranica
Možete vjerovati ovoj stranici.
Ništa loše neće se dogoditi vama ni vašem BodgeIt računu.
Primijetite kako je ciljno svojstvo obrasca iframe definiran odmah ispod njega i da takav okvir ima 0% visine i širine.
- Učitajte novu stranicu u preglednik u kojem je sesija pokrenuta. Ova snimka zaslona pokazuje kako stranica izgleda prilikom pregleda s preglednikom Razvojni alati:
Primijetite da je objekt iframe samo crna crta na stranici, a u Inspectoru možete vidjeti da sadrži stranicu profila korisnika BodgeIt. - Ako analizirate mrežnu komunikaciju koju je poduzela vaša CSRF stranica, možete vidjeti da ona zapravo podnosi zahtjeve za promjenu lozinke BodgeIt:
Kako radi…
Kada iz preglednika pošaljete zahtjev i već imate pohranjeni kolačić koji pripada ciljanoj domeni, preglednik će priložiti kolačić uz zahtjev prije nego što se pošalje. To je ono što kolačiće čini tako praktičnima kao identifikatori sesije, ali ova karakteristika kako HTTP radi je i ono što ga čini ranjivim na napad poput onog koji ste vidjeli u ovom članku.
Kada učitate stranicu u isti preglednik, gdje imate aktivnu sesiju u aplikaciji, preglednik će automatski dodati kolačić sesije na taj zahtjev. To se događa čak i ako se radi o drugoj kartici ili prozoru, a ova stranica upućuje zahtjev domeni na kojoj je sesija pokrenuta.
Ako poslužitelj ne potvrdi da zahtjevi koje prima zapravo potječu iz aplikacije, dopušta zlonamjernoj web lokaciji da upućuje pozive u ime legitimnih, aktivnih korisnika koji posjećuju ovu zlonamjernu web lokaciju dok su autentificirani na ciljnu domenu.
U testu penetracije web aplikacije, prvi kôd koji ste upotrijebili, onaj s dva tekstna polja i podnijeti gumb može biti dovoljan da dokaže prisutnost sigurnosne greške. Međutim, testiranje penetracije aplikacije može biti dio drugog angažmana, kao što je socijalni inženjering ili vježba crvenog tima. U tom će slučaju biti potreban dodatni napor kako bi se spriječilo da korisnik žrtve posumnja da se nešto događa.
U ovom ste članku koristili JavaScript za automatizaciju slanja zahtjeva postavljanjem događaja učitavanja na stranici i izvršavanjem metode slanja obrasca u funkciji rukovatelja događajima. Također ste koristili skriveni iframe za učitavanje odgovora na promjenu lozinke, tako da žrtva nikad ne vidi poruku da se promijenila njegova lozinka.
Ako vam je ovaj članak bio zanimljiv, možete istražiti Kuharica za testiranje web prodora Kali Linux - drugo izdanje kako biste otkrili najčešće ranjivosti na webu i spriječili ih da postanu prijetnja sigurnosti vaše web lokacije. Kuharica za testiranje web prodora Kali Linux - drugo izdanje daje vam vještine potrebne za pokrivanje svake faze penetracijskog testa - od prikupljanja podataka o sustavu i aplikaciji do identificiranja ranjivosti ručnim testiranjem.
