OWASP Top 10: Problemi sa umetanjem koda/znakova

Izvor: SIS Wiki
Skoči na: orijentacija, traži

Sadržaj

Uvod

U današnje vrijeme, kada se sve više oslanjamo na tehnologiju i softver za svakojake potrebe, nesigurne aplikacije su sve veći problem. Pa tako zbog nesigurnih aplikacija može nastradati sve od vaše osobne web stranice do financijske, zdravstvene, obrambene, energijske infrastrukture. Budući da se kompleksnost tehnologije svakim danom sve više povećava, s time se eksponencijalno povećavaju i problemi postizanja sigurnosti aplikacije. Čak se ni jednostavni sigurnosni propusti više ne mogu tolerirati.[1]
--Dhuzjak 20:16, 5. siječnja 2012. (CET)


Što je OWASP Top 10

OWASP Top 10 je projekt kojemu je cilj povećati svijest o sigurnosti aplikacija tako da identificira neke od najčešćih i najopasnijih prijetnji sigurnosti. OWASP Top 10 projekt postoji već 9 godina, dakle od 2003., a zadnje izdanje je bilo 2010. godine. Dokument koji izdaju je jedinstvena referenca na najčešće i najopasnije sigurnosne propuste u aplikacijama, zajedno s opisima preko kojih možete saznati da li je vaša aplikacija ranjiva na te propuste te kako se od njih zaštititi.[2]
U ovom projektu mi ćemo opisati problem s umetanjem koda/znakova koji se neumoljivo popeo na prvo mjesto kao najčešći sigurnosni propust kod web aplikacija u 2010. godini, dok je 2007. bio na drugom mjestu, a 2004. tek na šestom.[3][4][5]
--Dhuzjak 21:03, 5. siječnja 2012. (CET)


Problem s umetanjem koda/znakova

U probleme s umetanjem kodova/znakova spadaju problemi kao što su SQL, OS, LDAP, XPath, CRLF umetanje. Oni nastupaju kada se neprovjereni podatak šalje interpreteru kao dio naredbe ili upita. Taj neprovjeren i zlonamjeran podatak može prevariti interpretera tako da izvede neželjene naredbe ili pristupi neautoriziranim podacima.[6]
Opisat ćemo SQL, XPath, LDAP, CRLF, SSI, MX ubacivanje te ubacivanje OS naredbi.
--Dhuzjak 21:03, 5. siječnja 2012. (CET)

SQL Injection

SQL injection ili umetanje SQL koda je najpoznatiji propust umetanja znakova. Ako na web aplikaciji nisu uvedene primjerene zaštite čak i manje stručna osoba može izvesti ovakav napad. Napad se obično izvodi umetanjem posebno oblikovanog SQL koda u polja za pretraživanje ili upisivanje korisničkog imena i lozinke. Da bi napadač uspješno izveo napad on obično mora poznavati strukturu baze i SQL jezik.[7]
Postoje dva tipa SQL injectiona, napad prve i druge razine. Kod prve razine, SQL kod koji se umetne odmah se izvodi i čini neku štetu, dok kod napada druge razine napadač prvo umetne neke podatke u bazu, a kasnije, kada ih aplikacija dohvaća, izvršava se SQL injection i čini neku štetu.
Tipove SQL injectiona su sljedeći:

Svaki od ovih napada ću objasniti i popratiti s primjerima.
--Dhuzjak 19:51, 5. siječnja 2012. (CET)


Zaobilaženje prijave

Najjednostavniji oblik korištenja SQL injection-a je kod zaobilaženja legitimne prijave u sustav.
Da bi otkrili da li je aplikacija ranjiva na SQL injection napad najjednostavniji način jest da upišemo samo jedan navodnik i vidimo što će nam aplikacija odgovoriti. Ako odgovori da sintaksa upita nije valjana to nam govori da je aplikacija ranjiva na SQL injection.
Pod normalnim uvjetima da bi se korisnik mogao prijaviti u sustav on mora u dvije kućice upisati svoje korisničko ime i lozinku. Nakon toga aplikacija dohvaća to korisničko ime i lozinku i na temelju nje kreira SQL upit koji ako vrati pozitivan rezultat znači da u bazi postoji kombinacija tog imena i lozinke te onda korisnika pušta u sustav. Ako na primjer postoji korisnik imena „user“ s lozinkom „password“ u tablici „korsnici“ s atributima „korisnickoIme“ i „lozinka“, kreirat će se sljedeći SQL upit:

SELECT korisnickoIme FROM korisnici WHERE korisnickoIme = 'user' AND lozinka = 'password'

i ako taj upit vrati pozitivan rezultat aplikacija će pustiti korisnika u sustav. No ako ne postoji nikakva zaštita ili provjera unosa, napadač bi mogao iskoristiti takav propust da izvede bilo kakvu SQL naredbu. Na primjer, napadač bi u polja za unos mogao unijeti sljedeći niz znakova koji bi zavarao aplikaciju i pustio ga u sustav:

' OR '1'='1

U ovom slučaju SQL upit koji bi se kreirao bi izgledao ovako:

SELECT korisnickoIme FROM korisnici WHERE korisnickoIme = '' OR '1'='1' AND lozinka = '' OR '1'='1'

U tom slučaju baza više ne traži kombinaciju navedenog korisničkog imena i lozinke nego provjerava istinitost tvrdnje '1'='1', a budući da je ta tvrdnja uvijek istinita, cijeli WHERE dio upita će biti istinit i kao posljedica bit će vraćanje prvog korisničkog imena u tablici što znači da je vraćen pozitivni rezultat i aplikacija će pustiti napadača u sustav prijavljenog kao prvi korisnik u tablici.
Osim ovakvog oblika umetnutog koda, napadač može upisati bilo kakav kod koji je istinit, to ovisi o sintaksi koju koristi SQL upit. Razlike u SQL upitu mogu biti u vrsti navodnika koji se koriste (jednostruki, dvostruki) i da li se koristi zagrada ili ne. Napadač može pogoditi sintaksu metodom pokušaja i pogreške ili ju može saznati prikupljanjem podataka o strukturi i vrsti baze podataka.
Također se može upisati sljedeći kod samo u kućicu za korisničko ime:

' OR 1=1 --

To će generirati SQL upit koji će provjeravati samo korisničko ime, a lozinku neće jer je sve nakon provjere korisničkog imena zakomentirano sa dvije crtice (--).[9]
--Dhuzjak 20:04, 5. siječnja 2012. (CET)

Prikupljanje informacija o bazi

Da bi napadač lakše izveo napad on mora poznavati strukturu baze podataka. Tu su najkorisniji podaci o imenima tablica, atributima i vrstama podataka za atribute. Da bi napadač do njih došao, on koristi poruke o greškama. Te su poruke namijenjene programerima koji razvijaju aplikaciju da bi lakše našli grešku kod razvoja, ali ih napadač može iskoristiti za svoj napad.
Napadač namjerno ispune podatke s nekim SQL kodom i tako izazove grešku te proučavajući poruku o grešci može saznati korisne podatke o bazi. Vrste greški mogu biti sintaksna, logička i greška zbog pogrešnog tipa podatka. Iz sintaksne greške mogu otkriti parametre koji su ranjivi na SQL injection. Iz logičke greške mogu otkriti imena tablica i atributa, dok iz greške pogrešnog tipa podatka mogu saznati tipove podataka za pojedine atribute ali i imena atributa.
Primjer prikupljanja informacija o bazi je sljedeći:
Napadač bi mogao upisati sljedeći kod:

;SELECT @@VERSION--

A kao odgovor bi dobio verziju servera. Nakon što je saznao koji se server koristi on može nastaviti prikupljanje informacija o recimo imenima tablice.[10] Neka je u pitanju baza Microsoft SQL Server, napadač bi mogao umetnuti sljedeći kod:

convert(int, (SELECT TOP 1 name FROM sysobjects WHERE xtype = 'u'))

Tim kodom se pokušava dohvatiti prva korisnička tablica (xtype='u') iz tablice s metapodacima koja se zove „sysobjects“. Nakon toga ona se pokušava pretvoriti u integer, a budući da to nije moguće dolazi do greške pretvorbe tipova iz koje se napadač može uvjeriti da se doista radi o Microsoft SQL Serveru, te dobiva i pravo ime prve tablice.[11]
--Dhuzjak 20:12, 5. siječnja 2012. (CET)

Otkrivanje podataka iz baze

Napadaču je često cilj izvući iz baze podataka neke podatke koje bi kasnije koristio za daljnje maliciozne radnje. On tako može iskoristiti običnu formu za logiranje da izvuče podatke iz baze. Naime, kao što je već rečeno kod logiranja se obično kreira SELECT naredba. Ta naredba zapravo dohvaća nešto iz baze podataka. Ako napadač koristi naredbu UNION to mu omogućava izvršavanje više SELECT naredbi. Način na koji to radi jest da postojeću SELECT naredbu spoji sa svojom SELECT naredbom pomoću naredbe UNION. Sada napadač, ako zna imena tablica i atributa, može pristupati podacima iz bilo koje tablice preko standardne forme za logiranje. U kućicu za korisničko ime može umetnuti sljedeći kod:

' UNION SELECT brojKartice FROM kreditneKartice WHERE brRacuna=12345 --

Na temelju toga bi se kreirao sljedeći upit:

SELECT korisnickoIme FROM korisnici WHERE korisnickoIme = '' UNION SELECT brojKartice FROM kreditneKartice WHERE brRacuna=12345 --' AND lozinka = ''

Prvo, upit za prvu SELECT naredbu ne bi vratio ništa ako ne postoji korisnik s praznim korisničkim imenom, zatim bi se izvela druga SELECT naredba koja bi vratila broj kreditne kartice za dani račun, što programer nije zamislio, ali napadač jest. Na kraju budući da su nakon te naredbe dvije crtice, ostatak upita se ne bi izvodio.[12]
--Dhuzjak 20:24, 5. siječnja 2012. (CET)

Dodavanje i izmjena podataka u bazi

Za dodavanje podataka u bazu koristi se naredba INSERT, a za izmjenu već postojećih podataka u bazi koristi se naredba UPDATE pa tako i napadač može umetnuti SQL kod koji koristi te naredbe te tako dodati odnosno izmijeniti podatke u bazi. No da bi takav napad uspio napadač mora poznavati strukturu baze, odnosno imena tablica, atributa te vrstu podataka za pojedine atribute. Te se informacije mogu saznati običnim pogađanjem imena ili prikupljanjem informacija o bazi. Osim naredbi INSERT i UPDATE, napadač za ovu vrstu napada koristi i točku-zarez. Točka-zarez u SQL kodu označava kraj jedne naredbe nakon čega može započeti druga. Pa tako korištenjem točke-zarez-a napadač može iskoristiti postojeću SQL naredbu da umetne svoje naredbe koje sadržavaju INSERT i UPDATE da doda ili izmjeni podatke u bazi.
Pa bi tako u normalnu formu za logiranje umetnuo prvo sljedeći kod:

';

Pa bi generirani upit prvo tražio korisnika s praznim korisničkim imenom. Zatim se nailazi na točku-zarez koja označava kraj jedne naredbe i početak druge. Nakon te točke-zarez, napadač bi mogao iskoristiti naredbe INSERT ili UPDATE da umetne novog korisnika, odnosno sebe, u bazu i dodjeli mu bilokakve ovlasti. I na kraju svog umetnutog koda bi stavio dvije crtice čime bi ostatak generiranog upita zakomentirao i on se ne bi izvodio.[13]
--Dhuzjak 20:24, 5. siječnja 2012. (CET)

DoS napad

Denial of Service (DoS) napad je napad koji u najgorem slučaju može uništiti bazu podataka ili pak samo ne dozvoliti legitimnim korisnicima da koriste bazu. Najopasnija naredba za takav napad je:

DROP TABLE ime_tablice

Ona efektivno briše tablicu iz baze zajedno sa svim podacima koji su u njoj bili zapisani. Ako napadač uspije umetnuti ovakvu naredbu u aplikaciju može nanijeti veliku štetu. Da bi uspio umetnuti ovakav SQL kod mora naravno poznavati imena tablica do kojih može doći već prije spomenutim načinima. Zatim, za umetanje ovakvog SQL koda koristi već spomenutu točku-zarez. Pa tako ako imamo standardnu formu za logiranje koja traži korisničko ime i lozinku, ako nema nikakve provjere unesenih podataka, napadač može umetnuti slijedeći kod u kućicu za korisničko ime:

'; DROP TABLE korisnici –

Pa sada SQL upit koji se kreira da provjeri postojanje korisnika s danom lozinkom izgleda ovako:

SELECT korisnickoIme FROM korisnici WHERE korisnickoIme ''; DROP TABLE korisnici -- 'AND lozinka = ''

Kreirani SQL upit sada ne radi što je programer zamislio nego, prvo ispituje da li u bazi postoji prazno korisničko ime i ako ne postoji ne će vratiti ništa, ali zatim nailazi na umetnuti SQL kod koji efektivno briše tablicu „korisnici“ iz baze podataka. Nakon toga bi se trebala ispitivati lozinka ali je taj dio zakomentiran sa dvije crtice pa se taj dio koda ne izvodi.
Osim DROP TABLE, napadač za DoS napad može koristiti i naredbu SHUTDOWN koja samo gasi bazu podataka, a ne uništava ju. Kod koji bi umetnuo na isto mjesto kao i u prethodnom slučaju za izvođenje ovakvog napada je sljedeći:

'; SHUTDOWN --
[14]

--Dhuzjak 20:24, 5. siječnja 2012. (CET)

Udaljeno izvođenje naredbi

Većina SQL baza podataka dolazi s hrpom pohranjenih procedura koje olakšavaju rad s bazom, proširuju mogućnosti baze i omogućuju lakše povezivanje s operacijskim sustavom. Većinu tih pohranjenih procedura korisnik nikad ne koristi, a ako napadač sazna o kojoj je bazi podataka riječ na način koji smo opisali kod prikupljanja informacija o bazi podataka, on ih može iskoristiti za izvođenje napada. Napadač obično koristi procedura za napad na bazu podataka, ali može napasti i operacijski sustav. Nekad i same procedure sadrže ranjivosti (poput prelijevanja međuspremnika) koje napadač može iskoristiti za izvođenje malicioznog koda ili za povećanje ovlasti. Jednom kad napadač sazna koje pohranjene procedure postoje, on ih lako može iskoristiti korištenjem točke-zareza kako je bilo već na drugom primjeru objašnjeno. Neke od procedura koje napadač može iskoristiti su:

Pa tako ako imamo standardnu formu za logiranje možemo koristiti naredbu xp_cmdshell na sljedeći način. Sljedeći kod upišemo u formu za unašanje korisničkog imena:

'; exec master..xp_cmdshell 'net user test testpass /ADD'--

pa će kreirani upit izgledati ovako:

SELECT korisnickoIme FROM korisnici Where korisnickoIme = ''; exec master..xp_cmdshell 'net user test testpass /ADD'-- 'AND lozinka = ''

Prvi dio upita neće vratiti ništa ako ne postoji korisnik s praznim korisničkim imenom. Drugi dio upita izvodi pohranjenu proceduru xp_cmdshell. Samo tijelo procedure zapravo dodaje novog korisnika (napadača) u bazu u popis korisnika koji imaju pristup poslužitelju. Ostatak koda se ne izvršava jer je naravno zakomentiran.
No ipak ovu naredbu može izvršavati samo korisnik koji ima administratorske ovlasti, ali uvijek postoji mogućnost da su postavke drugačije postavljene što napadaču daje šansu za napad.[15]
--Dhuzjak 20:31, 5. siječnja 2012. (CET)

Povećanje ovlasti

Kod povećanja ovlasti napadač nema na umu odmah iskoristiti propust već namjerava umetnuti posebno oblikovan SQL kod koji će mu omogućiti iskorištavanje aplikacije/baze kasnije, odnosno on si namjerava povećati ovlasti nad željenom aplikacijom/bazom da bi kasnije mogao obavljati maliciozne radnje. Ova vrsta napada je napad druge razine. Ovu vrstu napada ću pojasniti sljedećim primjerom.
U ovom primjer napadač sebi želi dodijeliti administratorske ovlasti. Za to mora poznavati samo korisničko ime administratora koje je u najvećem slučaju „admin“. No čak i ako nije nego je neko slično, napadač može i to iskoristiti ako kod upisa umjesto „admin“ napiše „LIKE %admin%“ pa će SQL upit vratiti imena poput „administrator“, „admin2“ i slična imena.
Za izvođenje ovakvog napada napadač se prvo mora registrirati. Kod registracije mora upisati korisničko ime i neke druge podatke koji nisu bitni. Za korisničko ime upisuje:

admin' --

Ako nema nikakve provjere, aplikacija će mu dopustiti to korisničko ime i pohraniti ga u bazu. Za sada još nije izveden nikakvi napad. Da bi se izveo napad, aplikacija mora pristupiti tom korisničkom imenu/umetnutom kodu. Najlakši način za to jest da napadač zatraži promjenu lozinke, što većina aplikacija danas omogućava. To se obično obavlja tako da korisnik mora upisati staru lozinku i novu lozinku te je onda aplikacija u bazi izmjeni. Kod takvog upisivanja kreira se nešto slično kao sljedeći SQL upit:

UPDATE korisnici SET lozinka = 'novaLozinka' WHERE korisnickoIme = 'korIme' AND lozinka = 'staraLozinka'

U napadačevom slučaju SQL upit će konkretno glasiti ovako:

UPDATE korisnici SET lozinka = 'novaLozinka' WHERE korisnickoIme = ' admin' --' AND lozinka = 'staraLozinka'

Budući da dvije crtice označavaju komentar, sve nakon dvije crtice će se i smatrati komentarom i neće se izvoditi, izvest će se samo dio koda gdje se postavlja nova lozinka za korisnika „admin“, a budući da je „admin“ zapravo administrator sustava, napadač je ovime efektivno dodijelio sebi administratorske ovlasti te je administratoru oteo korisnički račun.[16]
--Dhuzjak 20:31, 5. siječnja 2012. (CET)


Umetanje SQL koda u URL adresu

SQL injection je moguće izvesti i umetanjem koda u URL adresu. Ako se kod učitavanja stranice kreira SQL upit, napadač može i ovdje iskoristiti sve do sada opisane načine napada odnosno umetanja SQL koda. Jedno takvo umetanje ću objasniti na sljedećem primjeru. Ako napadač pristupa stranici sa slikama URL adresa bi mogla izgledati ovako:

http://www.slike/index.asp?id=5

„id=5“ znači da se prikazuje peta slika. Jednostavna manipulacija ovom adresom bi mogla biti da se promijeni pet na npr. 4, pa će se prikazati četvrta slika. Ovakva manipulacija ne izaziva neku štetu, ali daleko malicioznije radnje je moguće tu izvesti. Ako se na temelju URL adrese kreira upit na sljedeći način:

SELECT * FROM slike WHERE id = 'idSlike'

Napadač bi mogao umetnuti sljedeći kod:

4; DROP TABLE slike

Pa bi nova adresa izgledala ovako:

http://www.slike/index.asp?id=4;%20DROP%20TABLE%20slike

A upit koji bi se proslijedio bazi bi izgledao ovako:

SELECT * FROM slike WHERE id = '4; DROP TABLE slike

Ovaj bi upit prvo dohvatio četvrtu sliku, a zatim bi se izvela druga naredba budući da je odvojena točkom-zarez, a druga naredba uništava tablicu „slike“ i sve podatke u toj tablici.
Kao što sam i rekao i ostali opisani napadi umetanjem SQL koda se mogu izvesti na sličan način kao i ovaj.[17]
--Dhuzjak 20:59, 5. siječnja 2012. (CET)


Slijepo umetanje SQL koda

Kao što sam već rekao, da bi napadač uspješno izveo napad umetanjem SQL koda on mora poznavati neke podatke o bazi, o vrsti baze, imena tablica, atributa i tipove podataka za atribute. Kako do njih doći je također opisano, dakle korištenjem SQL upita da mu se ispišu podaci koje želi, korištenjem poruka greške ili korištenjem procedure sp_makewebtask.
Ali ako se onemogući ovakvo prikupljanje podataka, napadaču se uvelike otežava prikupljanje informacija i izvođenje napada, ali to je još uvijek moguće. U tom slučaju se radi o slijepom umetanju SQL koda. Postoje dvije metode kojima napadač može doći do željenih informacija, a ja ću objasniti obadvije.
Prvi je način da napadač umeće ispravni i neispravni SQL kod i promatra reakciju web stranice. Ako umetne neispravni kod, u idealnom slučaju bi stranica odmah izbacila informacije koje napadaču trebaju, ali i ako ih ne izbaci ona će se sigurno ponašati nekako drugačije što može biti korisno napadaču.
Ako napadač želi provjeriti ranjivost stranice iz prethodnog primjera:

http://www.slike/index.asp?id=5

on umeće sljedeći kod:

5 AND 1=1

U ovom slučaju napadač zna kako izgleda normalna stranica s petom slikom. Ako URL s umetnutim kodom vrati istu stranicu kao i bez koda to znači da je stranica ranjiva na SQL injection. Ako pak vrati nešto drugačiju stranicu ili se stranica uopće nije promijenila to znači da je došlo do greške prilikom izvođenja SQL upita i stranica nije ranjiva na SQL injection.
Drugi način prikupljanja informacija je korištenjem naredbe WAITFOR. Ovom naredbom se odgađa izvođenje SQL upita proizvoljan broj sekundi. Mjerenjem odaziva web stranice i korištenjem naredbe WAITFOR i if/then grananja napadač može dobiti informacije o strukturi baze. Takvo prikupljanje informacija je dugotrajno i zamorno ali se može automatizirati.
Da bolje objasnim, prikazat ću to na sljedećem primjeru.
Ako napadač želi saznati imena tablica on za to može koristiti običnu formu za logiranje korisnika. Za ovaj napad mora znati korisničko ime jednog korisnika, ali to nije problem jer se i sam može registrirati pod nekim pseudonimom. Zatim kod prijave umeće sljedeći kod:

korisnik' AND ASCII (SUBSTRING ((SELECT TOP 1 name FROM sysobjects), 1, 1)) > X WAITFOR 5 --

SQL upit koji se prosljeđuje bazi onda izgleda ovako:

SELECT korisnickoIme FROM korisnici WHERE korisnickoIme =' korisnik' AND ASCII (SUBSTRING ((SELECT TOP 1 name FROM sysobjects), 1, 1)) > X WAITFOR 5 -- AND lozinka = ''

Naredba SUBSTRING se koristi za dohvat prvog znaka iz imena tablice iz baze podataka. Zatim se provjerava da li je vrijednost tog znaka veća ili manja od X. Ako je veća zakašnjenje u odazivu će biti 5 sekundi, a ako nema zakašnjenja napadač može umjesto X upisati neko drugo slovo i pratiti odaziv.
Kao što sam rekao ovakav način je dugotrajan i zamoran jer se mora pogađati jedno po jedno slovo, ali iskusnom napadaču nije teško automatizirati ovaj proces.[18]
--Dhuzjak 20:59, 5. siječnja 2012. (CET)


Kako spriječiti umetanje

Sprječavanje umetanja tako da se izmijeni programski kod i uvedu dodatne provjere. To će obraniti web aplikaciju od većine napada no neće ga potpuno spriječiti, ali će uvelike otežati napadačima izvođenje napada što će ih obično obeshrabriti te će priječi na neke druge ranjivije stranice.
Sprječavanje umetanja se temelji na tome da se neprovjereni podaci drže podalje od naredbi i upita. Najbolje je koristiti sigurne API-e čime se zaobilazi korištenje interpretera ili se pruža parametrizirano sučelje. No treba paziti na API-e koji se čine parametrizirani no još uvijek mogu dozvoliti umetanje, kao što su pohranjene procedure. Ako takvi API-i nisu dostupni potrebno je oprezno izbjeći specijalne znakove. Validacija inputa pomoću „whitelisting-a“ sa prikladnom kanonizacijom također pomaže u sprječavanju umetanja.[19]
Što se tiče baze podataka, dvije su bitne stvari za zaštitu od napada. Korištenje netipičnih imena tablica i atributa te ograničavanje ovlasti. Pa tako ako se koriste netipična imena napadač će se morati dodatno potruditi da ih otkrije umjesto da iz prve pogodi neko uobičajeno ime tablice kao što je npr. „korisnici“. Osim toga treba korisnicima onemogućiti izvođenje većine SQL naredbi, osim onih koje su im nužne za rad, npr. omogućiti im izvođenje samo naredbe SELECT, dok bi samo administrator mogao koristiti i ostale, potencijalno opasnije, naredbe poput DROP TABLE.
Kod polja za unos podataka potrebno je uprogramirati dodatne procedure za ograničavanje duljine i tipova podataka. Npr. broj znakova za unos korisničkog imena i lozinke se može ograničiti na npr. 10 znakova jer bi to trebalo biti dovoljno. Na mjesta gdje se unašaju brojke treba uvesti provjeru da li je korisnik zaista i napisao samo brojke, a ne neki SQL kod.
Sama provjera unesenih podataka bi se trebala obavljati na poslužiteljskoj strani jer u suprotnome napadač može dohvatiti stranicu i obrisati dio gdje se provjeravaju podaci.
Zatim treba zabraniti unašanje određenih znakova poput navodnika, točke-zarez, dvije crtice, SQL naredbi poput INSERT, DROP TABLE te pohranjenih procedura poput xp_cmdshell. Ti znakovi korisnicima sigurno neće trebati a napadač bi ih mogao iskoristiti za izvođenje napada kako je već bilo i opisano.
Osim toga postoje i zaštite koje se mogu uvesti na poslužitelju. Prvo je ograničavanje pristupa aplikaciji na samo one dijelove koji su joj nužni za obavljanje zadataka. Zatim ograničiti informacije koje se pružaju prilikom poruka greške i prikazati samo npr. stranicu na kojoj piše „500 Server Error“. Te server treba naravno neprestano nadgledati, nadograđivati, čistiti od nepotrebnih podataka i sl.[20]
--Dhuzjak 20:59, 5. siječnja 2012. (CET)


Korisni alati

Za kraj bi još samo spomenuo neke korisne alate koji ili provjeravaju ranjivost na SQL injection ili do neke mjere štite od takvog napada. To su:
Dodatak za Firefox „SQL Inject Me“, SQL Injection Test dostupan na stranici: hackertarget.com/free-sql-scan, programski paketi sqlmap i Pangolin. Oni svi provjeravaju ranjivost na SQL injection. Još jedan koristan paket koji zapravo služi za sprječavanje napada jest GreenSQL.[21]
--Dhuzjak 20:59, 5. siječnja 2012. (CET)


Praktični dio

Za praktični dio sam htio napraviti neku ranjivu web aplikaciju na kojoj bi demonstrirao navedene napade ali sam u međuvremenu naletio na već gotovu takvu aplikaciju koja služi upravo za edukacijske svrhe, pa nisam htio izmišljati toplu vodu nego sam uzeo i instalirao tu aplikaciju na računalu te ću na njoj pokazati opisane ranjivosti.
Dana aplikacija se može skinuti na: http://www.dvwa.co.uk/.
Za osposobljavanje te stranice morao sam instalirati i XAMPP web server koji je dostupan na http://www.apachefriends.org/en/xampp.html.
Nakon što sam sve instalirao mogu pokrenuti aplikaciju i logirati se danim mi korisničkim imenom i lozinkom: admin, password.
Slika 1. dvwa početna stranica.JPG

Na početnoj stranici možete vidjeti da je omogućeno testiranje nekoliko vrsta napada što uključuje SQL injection, blind SQL injection, CSRF, file inclusion i td.
No prije samog testiranja trebalo je kreirati bazu te postaviti sigurnost na „Low“ jer nam s defaultnim postavkama na „High“ ništa ne bi radilo.
Nakon toga možemo krenuti na samo testiranje SQL injectiona na sljedećoj stranici.
Slika 2. SQL injection.JPG

Aplikacija nam nudi jedno jedino polje za upisivanje korisničkog Id-a preko kojeg ćemo izvoditi naš napad. Pa prvo što ćemo napraviti jest provjeriti da li je aplikacija doista ranjiva na SQL injection tako da upišemo samo jedan navodnik i vidimo što će nam aplikacija odgovoriti.
Kao odgovor dobivamo sljedeću poruku greške:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''''' at line 1

Koja nam zapravo govori da smo poremetili sintaksu upita koji se kreira prilikom unosa korisničkog ID-a što zapravo znači da je aplikacija ranjiva na SQL injection.
Sljedeće ćemo iskoristiti trik za logiranje koji bi trebao producirati barem jedan validan user ID.

' OR '1'='1

Slika 3. ' OR '1'='1.JPG

SQL injection je urodio plodom. Aplikacija nam je ispisala imena i prezimena svih korisnika u bazi. Za sada smo saznali da SQL upit koji se kreira na temelju našeg unosa provjerava ID koji smo unijeli i na temelju njega iz tablice vadi ime te prezime i ispisuje ga na ekran. No podaci koji se ispisuju nam baš i ne koriste previše. Mi bi htjeli doznati korisnička imena i lozinke. Za to nam trebaju imena tablica i atributa. Da bi njih doznali moramo koristiti SQL upit koji se kreira na temelju našeg unosa. Za to ćemo koristiti naredbu UNION i nakon nje SELECT koji će nam vračati informacije koje želimo.
Prvo, možemo doznati verziju servera te ime baze sa sljedećim kodom:

' UNION SELECT database(),version() --

Prvi navodnik služi da zatvorimo provjeru user ID-a, pa prvi SQL upit kojeg stvara aplikacija neće vratiti ništa budući da ne postoji korisnik s praznim ID-om. Zatim slijedi naš SELECT upit koji selektira dvije stvari budući da prvi upit isto selektira dvije stvari, u suprotnome ne bi radilo. Prvo koristimo database() koji vraća ime baze, a u drugom dijelu koristimo version() koja vraća verziju servera.
Slika 4. Ime baze i verzija servera.JPG

Zatim sa sljedećim kodom dohvaćamo imena tablica u bazi.

' UNION SELECT null,TABLE_NAME FROM information_schema.TABLES where table_schema='dvwa' --

Ovaj puta prvi dio SELECT naredbe stavljamo na null jer nam ne treba. Drugi dio zapravo govori da se odaberu imena tablica iz tablice s metapodacima i to samo za bazu kojoj smo prije saznali ime. Rezultate možemo vidjeti na sljedećoj slici.
Slika 5. Imena tablica.JPG

Sada znamo da u bazi postoje dvije tablice, „gusetbook“ i „users“. Sa sljedećim kodom dohvaćamo imena atributa u pojedinim tablicama.

' UNION SELECT null,column_name FROM information_schema.columns where table_name='guestbook' --

i

' UNION SELECT null,column_name FROM information_schema.columns where table_name='users' --

Dakle ovaj puta dohvaćamo imena kolumna iz tablice s metapodacima i to samo za tablicu koju smo zadali. Rezultati za „guestbook“ nam nisu zanimljivi, ali za tablicu „users“ već jesu.
Slika 6. Atributi za tablicu users..JPG

Sad znamo da se u tablici „users“ nalaze podaci o user_id-u, imenu, prezimenu, korisničkom imenu, lozinci i avataru. Nas zanimaju korisnička imena i lozinke. Do njih dolazimo sljedećim kodom.

' UNION SELECT user,password FROM users --

Dakle jednostavno, odabiru se korisnička imena i lozinke iz tablice „users“.
Slika 7. Korisnička imena i lozinke..JPG

Iako sada imamo korisnička imena i lozinke to nam ništa ne znači jer su lozinke očito kriptirane. Sljedeći korak bi bio razbiti kriptirane lozinke no to nije tema ovog rada.
Osim ovog možemo još i pristupiti drugim tablicama osim onima kojima originalni SQL upit pristupa. To ćemo učiniti sljedećim kodom.

' union select null, comment from guestbook --

Dakle odabire se atribut „comment“ iz tablice „guestbook“ i dobijemo sljedeći rezultat.
Slika 8. Dohvaćanje podataka iz drugih tablica..JPG
--Dhuzjak 23:20, 6. siječnja 2012. (CET)

XPath Injection

XPath

XPath je jezik koji opisuje način na koji se može pristupiti stavkama u XML dokumentima upotrebom sintakse koja se temelji na putanji s obzirom na logičku strukturu ili hijerarhiju dokumenta. Tako se pojednostavnjuje pisanje programskih izraza budući da nije potrebno svaki izraz temeljiti na XML oznakama i njihovom redoslijedu u dokumentu.

Glavna razlika između jezika XPath i drugih jezika je tome što Xpath specificira putanju umjesto da pokazuje na skup ili slijed znakova, riječi ili drugih elemenata.

Xpath koristi koncept „čvora“ (eng. concept node, točka početka putanje adrese), logičkog stabla koje se nalazi u svim XML dokumentima, te koncepte kojima se izražava veza (odnos, relacija) definirana u XML skupu informacija, a one su predak (ancestor), atribut (attribute), dijete (child), roditelj (parent), kao i sam koncept(self). [22]

Također Xpath posjeduje library koji se sastoji od 100 ugrađenih funkcija poput Boolean vrijednosti, usporedbu datuma i vremena, string i numeričke vrijednosti i td. U nastavku se nalazi primjer XML datoteke naziva Korisnici.xml. 

  <?xml version="1.0" encoding="UTF-8"?>
  <korisnici> 
      <korisnik>  
          <ime>Ivan</ime>
          <prezime>Horvat</prezime> 
          <loginID>abc</loginID> 
          <lozinka>ivohoror9</lozinka> 
      </korisnik> 
      <korisnik>  
          <ime>Chuck</ime>
          <prezime>Norris</prezime>
          <loginID>xyz</loginID> 
          <lozinka>dnnpass</lozinka> 
      </korisnik> 
      <korisnik>  
          <ime>Nikke</ime>
          <prezime>Knatterton</prezime>
          <loginID>cba</loginID> 
          <lozinka>ulala123</lozinka> 
      </korisnik> 
      <korisnik>  
          <ime>Ana</ime>
          <prezime>Novak</prezime>
          <loginID>zyx</loginID> 
          <lozinka>9meme</lozinka> 
      </korisnik> 
 </korisnici>

Xpath upit: 

 
Set xmlDoc=CreateObject("Microsoft.XMLDOM")
xmlDoc.async="false"
xmlDoc.load("korisnici.xml")
xmlobject.selectNodes("/korisnici/korisnik/loginID/text()")


Kada aplikacija treba vratiti određene podatke na temelju unosa korisnika, ona šalje Xpath upit koji se izvršava na serveru. [23]

Rezultat gore napravljenog upita bio bi: abc. Prema[24]

--kmejas 18:45, 5. siječnja 2012. (CET)

Definicija napada

Definicija

Xpath Injection je vrsta napada na Web stranice upotrebom Xpath upita nad korisničkim podacima. Ukoliko web aplikacija ugrađuje nezaštićene podatke u Xpath upit, isti je moguće promijeniti te se on neće ponašati u skladu s prvobitnom namjenom.[25]


XPath injection napadi su veoma slični SQL injection napadima. Naime kod klasičnih web arhitektura aplikacije spremaju podatke na podatkovni server. Server može pohranjivati podatke u različitim formatima koji mogu biti relacijske tablice (RDMBS), LDAP, XML i td.[26]

Takvi napadi su mogući kada web stranica koristi korisničke informacije za kreiranje upita nad XML podacima. Napadač lako može saznati kako su XML podaci strukturirani ili dobiti pristup podacima za koje nema prava pristupa na način da namjerno stranici pošalje pogrešne podatke ili posebno oblikovane upite.

Xpath se standardno upotrebljava za vršenje upita nad XML podacima i sastoji se naredbi (koda) koje čine XML upit i pomoću kojih se pronalaze pojedine informacije. [27]

Vrste Xpath Injectiona

Zaobilaženje autentikacije (eng. Bypassing Authentication)

S obzirom da su relacijske baze podataka većinski zastupljene, SQL Injection je dugo bio omiljen način napada na baze.

Npr. aplikacija se povezuje na bazu upotrebom tablice korisnika. Da bi korisnik dobio pristup potrebno je najprije formirati SQL upit koji korisnik mora zadovoljiti točnim unosom login podataka. To bi izgledalo ovako: 

Select * from korisnici where LoginID=' ' and lozinka=' '

No ako korisnik u polje loginID unese: 

abc' or 1=1 --

upit bi izgledao ovako: 

Select * from korisnici where loginID = 'abc' or 1=1 -- 'and lozinka=' '

Dakle kao što je vidljivo iz primjera napadač pogađa da je loginID abc, te se osigurava unosom koji je uvijek točan „1=1“. Nadalje koristi oznaku za komentare „--“ u SQL-u te se kod koji dolazi nakon te oznake niti ne izvodi. Na taj način dobiva pristup aplikaciji.

Budući da kod Xpatha ne postoji ekvivalent „--“ za komentiranje dijelova upita, postupak kod Xpatha se razlikuje u sljedećem.

Ako imamo sljedeći kod:[28] 

String(//korisnici[loginID/text()=' " + txtLoginID.Text + " ' and lozinka/text()=' "+ txtlozinka.Text +" '])

i korisnički unos je: 

abc' or 1=1 or 'a'='b

upit izgleda ovako: 

String(//korisnici[loginID/text()='abc' or 1=1 or 'a'='b' and lozinka/text()=''])

gdje kod: 

loginID='abc' or 1=1 or 'a'='b' and lozinka/text()=' '

možemo tumačiti kao: A OR B OR C AND D.

Pa budući da logički operator AND ima veći prioritet od operatora OR, gore napisani izraz se također može tumačiti kao: (A OR B) OR (C AND D). Stoga ukoliko je A ili B točno, izraz će se protumačiti kao TRUE bez obzira na (C AND D). U ovom slučaju B je 1=1, što znači da je (A OR B) uvijek točno i da je izraz uvijek točan te se napadaču omogućava prijava na sustav. [29]

Izdvajanje strukture XML dokumenta (eng. Extracting the XML document structure)

Napadač može doći do strukture XML dokumenta koristeći upit za zaobilaženje autentikacije objašnjenom u prijašnjim odlomcima. Ako pretpostavimo da je napadač pogodio (ili na neki način saznao) ili pak samo želi provjeriti da li je naziv prvog podčvora (eng. sub-node) u XML dokumentu loginID, vjerojatno bi unio u polje za unos, nešto poput sljedećeg: 

abc' or name(//korisnici/loginID[1]) = 'loginID' or 'a'='b

tada dobivamo sljedeći upit koji provjerava da li je naziv drugog podčvora loginID. 

String(//korisnici[loginID/text()='abc' or name(//korisnici/loginID[1]) = 'loginID' or 'a=b' and lozinka/text()=''])

Napadač na taj način, metodom pokušaja i pogreške može provjeriti različite čvorove u XML dokumentu. Ako rezultat XPath upita bude uspješna autentikacija napadač može doći do više korisnih informacija, odnosno strukture cijelog dokumenta.

Budući da bi to mogao biti poprilično dug i zamoran postupak, napadaču je jednostavnije napisati skriptu koja šalje različita XPath ubacivanja koda, te izdvaja dio ili pak cijeli XML dokument sa sustava. [30],[31]

Blind Xpath Injection

Kod klasičnog Xpath Injectiona, napadač se može prijaviti na sustav bez valjanog korisničkog imena ili lozinke, no da bi saznao više podataka, odnosno podatke o drugim korisnicima mora uložiti ipak malo više napora. Tome služi Blind Xpath Injection.

Kod provođenja ovakvog oblika napada, napadač nema saznanja o strukturi XML dokumenta no ipak je u prednosti u odnosu na Blind SQL Injection napad. Tome je zaslužno postojanje funkcija za ispitivanje XML indeksiranja (eng. XML Crawling) što pak za krajnji cilj može imati upoznavanje strukture samog dokumenta. Blind Xpath Injection spada u grupu "potpunih" napada budući da su svi podaci izloženi napadu te je na taj način napadaču omogućen pristup do cijelog XML dokumenta.

Postoji nekoliko tehnika za izvršenje takvog napada. One su Xpath Crawling i Boolenizacija Xpath upita.


Boolenizacija Xpath upita

Koristeći metodu Boolenizacije napadač može saznati ako je dani XPath izraz True ili False. Najjednostavniji je primjer pokušaja prijave na sam sustav. Kao što je već bilo navedeno u prijašnjim primjerima, napadač će se uspješno prijaviti na sustav ako je takav izraz "True", dok logički, neuspješna prijava bila bi jednaka "False".

No ako se napadač fokusira na pojedini znakovni niz (eng. string), može otkriti i cijelu riječ - cjelinu, uzastopnom provjerom svakog od znakova unutar klase/dosega kojem znakovni niz pripada.

Koristeći funkciju koja kao rezultat vraća duljinu znakovnog niza, napadač može lako doći do duljine takvog niza. S odgovarajućem brojem ponavljanja funkcije pronalaženja znakova unutar niza (S, N, 1) napadač može pronaći cijeli znakovni niz. Pri čemu je S-znakovni niz, N-početni znak, a "1" predstavlja sljedeći znak brojeći od znaka "N". 



<?xml version="1.0" encoding="UTF-8"?>
<podaci>
   <korisnik>
      <login>admin</login>
      <lozinka>test456</lozinka>
      <titula>SuperUser</titula>
   </korisnik>

   <korisnik>
      <login>user</login>
      <lozinka>ivo123</lozinka>
      <titula>User</titula>
   </korisnik>
</podaci>

Funkcija: 

string-length(//korisnik[position()=1]/child::node()[position()=2])

vraća duljinu drugog niza znakova (7), korisnika oznake na poziciji 1 (admin) 

substring((//korisnik[position()=1]/child::node()[position()=2),1,1)

vraća prvi znak niza istog korisnika ('t'). [32]

Xpath Crawling

Da bi došao do strukture XML dokumenta napadač može koristiti sljedeći izraz: 

count(//korisnik/child::node()

Kao rezultat vraća broj čvorova, u ovom primjeru dva (2).

Ako pak koristi 

string-length(//korisnik[position()=1]/child::node()[position()=2])=6

napadač saznaje da li se drugi znakovni niz ("lozinka") prvog čvora korisnik ("admin"), sastoji od 6 znakova. 

 substring((//korisnik[position()=1]/child::node()[position()=2]),1,1)="a"

Ovaj upit vraća TRUE ili FALSE ovisno o tome da li je "a" prvo slovo lozinke za korisnika "admin".

Popis ostalih XPath funkcija može se vidjeti slijedeći poveznicu

Budući da zbog Boolenizacije broj upita može biti poprilično velik (nekoliko tisuća i više) taj se napad ne provodi ručno. Da bi se napisao program potrebno je znati nekoliko osnovnih XPath funkcija, čime se može doći do strukture dokumenta kao i popratnih podataka. [33]

Prevencija XPath napada

S obzirom na to da su Xpath ubacivanja veoma slična SQL ubacivanjima koda, metode sprječavanja su podjednake kao i za sprječavanje ostalih napada ubacivanjem koda.

Validacija unosa

Postoji najbolja praksa koji bi trebalo slijediti u svrhu sprječavanja XPath napada, a takve smjernice obuhvaćaju:

Parametrizacija upita

Na ovaj način se XPath upiti ne kreiraju korisničkim unosom, već su stvoreni prije nego što je program uopće pokrenut (eng. precompiled XPath). [34] Više o tome na Precompiled XPath.

Ako se proslijede parametri niže navedenom upitu 

"//korisnici[loginID/text()=' " + txtloginID.Text + " ' and lozinka/text()=' "+ txtlozinka.Text +" ']"

dobivamo sljedeći upit: 

"//korisnici[loginID/text()= $loginID and lozinka/text()= $lozinka]"

Unos ne formira upit, već umjesto toga traži vrijednost u XML dokumentu koju ne uspijeva pronaći. Napad je spriječen. [35],[36] --kmejas 19:50, 5. siječnja 2012. (CET)

Alati za provjeru ranjivosti

--kmejas 15:08, 6. siječnja 2012. (CET)

Praktični dio

Primjer 1.

Na početku ću prikazati osnovni Xpath napad koji je veoma sličan SQL napadu.

Najprije je potrebno skinuti WebGoat alat sa sljedeće adrese te zadovoljiti nekoliko pretpostavki.

Dakle potrebno je:

Početni ekran Webgoat.jpg

Biramo Injection flaws te zatim Xpath. Dobiva se zadatak u kojem su dani osnovni podaci za jednog korisnika te je potrebno otkriti podatke ostalih korisnika. Ako se ulogiramo s danim podacima dobivamo njegove detaljnije podatke, što je vidljivo na slici niže (gore su prikazani podaci za prijavu).

Mike logiran.jpg


Upotrebom prije spomenutih tehnika dolazi se do rješenja krajnjeg zadatka. Dakle da bi prevarili sustav koristimo se klasičnom tehnikom koja je specifična za SQL injection napade odnosno zaobilaženjem autentikacije.

Dakle u polje za korisničko ime unosimo: 

 Mike'or 1=1 or 'a'='a

dok umjesto lozinke možemo unijeti bilo što.

Rješenje.jpg

Izvršena je prijava na sustav i to na način da nas sustav prepoznaje kao prvog korisnika koji je unešen u sustav. Podaci kojima je to učinjeno vidljivi su na slici. Važno je primjetiti da se umjesto "Mike" moglo upisati bilo koje ime, što vrijedi i za lozinku, budući da sustav već ima zadovoljen uvjet za prijavu.

Primjer 2.

U ovom dijelu dati će se prikaz načina korištenja aplikacija WebGoat te XPATH Blind Explorer u skladu s prije navedenim činjenicama vezanima uz XPath Injection. Da bi saznali više potrebno je uložiti više truda, napora i potrebni su dodatni alati poput alata Xpath Blind Explorer koji je predstavljen na Black_Hat 2011 konferenciji. Naime njegovom upotrebom moguće je doći do cijele strukture Xml dokumenta. Potrebno mu je dati nekoliko obaveznih podataka poput metode GET ili POST, te ukoliko se radi o POST metodi, URL zahtjeva te dodatne parametre koje je potrebno iščitati iz izvornog koda aplikacije. Da bi si olakšali možemo koristiti Firebug ili pak neki drugi dodatak / program kako bismo saznali potrebne podatke iz izvornog koda.

Opet je potrebno zadovoljiti nekoliko pretpostavki:

Za Xpath Blind Explorer su nam potrebni sljedeći podaci: URL i metoda zahtjeva, ključna riječ koja potvrđuje TRUE ili FALSE kao i HTTP Header u kojem navodimo Cookie da bi prošla autentikacija kod WebGoata.

Parametri.jpg

Dakle iz Firebug konzole koja prikazuje izvorni kod (Inspect - DOM) možemo iščitati da je adresa zahtjeva: http://localhost/webgoat/attack?Screen=539&menu=1200 (baseURI), Parametri: Username, Password i SUBMIT;

Niže je prikazana slika s označenim parametrima u Firebug konzoli.


Firebug.jpg


Ključnu riječ koja potvrđuje TRUE smo saznali nakon prve prijave u sustav i ona je: "468100".

Ako usporedimo podatke za koje smo označili da nam WebGoat pokaže iznad uspješne prijave, možemo vidjeti da se oni poklapaju.

Sada unosimo podatke koje smo saznali u Xpath Blind Explorer, slika ekrana s prvog taba se nalazi niže:

Drugi screen xpathxx.jpg

Dakle budući da svi od navedenih alata imaju osobite bugove pa ili ne rade ili se ruše (potrebno uzeti u obzir da je ovo rađeno u virtualnom okruženju gdje je ponekad radilo, ponekad ne).

HTTP header sam najprije saznala s alatom Paros, budući da Burp Suite ne voli baš raditi, pa čisto radi usporedbe. Slika se nalazi niže.

Paros.jpg

Na idućoj slici se nalazi slika drugog taba Xpath Blind Explorera nakon što smo saznali HTTP Header koji nam je potreban, za to nam je potreban program kao gore navedeni Paros,Webscarab, Burp Proxy...

Drugitabexplorer.jpg

Iduća slika prikazuje parametre u alatu Burp Suite.

Burpsuiteparametri.jpg

Na idućoj slici možemo vidjeti funkcionalnost Burp Suite alata decoder kojom dekodira autentikaciju.

Dekoder.jpg

Dakle vršimo testiranje za uvjet True uz pomoć vraćene ključne riječi, vidimo da nam je Burp vratio kako zapravo izgleda prijava na sustav i da je kod za ubacivanje "'%20and%20'1'='1" smješten na kraju svih parametara, što pak znači da XPath Blind Explorer tretira više parametara kao jedan.

Burp parametri.jpg

Dakle jedan dio se sastoji od Username dok drugi dio od URL-a. Budući da se kod za ubacivanje nalazi na kraju svih parametara potrebno je promijeniti njihov redoslijed. Dakle sada se parametar za lozinku nalazi na kraju i to izgleda ovako: 

SUBMIT=Submit&Username=Mike&Password=test123


Zamjena xpath prvi screen.jpg

XPath Blind Explorer tretira sve parametre kao jedan pa će se između parametara u URL nalaziti "&" (također se možemo uvjeriti da je to u ovom slučaju regex "(%26)" te je isto potrebno zamijeniti sa "&".) Tj. iz "%26" što nije URL kodirano, primjenom URL kodiranja dobivamo "&". U zamjeni će nam pomoći Burp Suite sa svojom opcijom "match and replace", što je vidljivo na slici niže.URL encoding

Reg burp.jpg

Reg burp1dodano.jpg

Nakon toga mijenja se izgled URL-a, odnosno kodiranja znakova. Pokrećemo opciju dohvaćanje XML koda (<GET XML>)i nakon određenog vremena Blind Xpath Explorer prikazati će XML strukturu dokumenta koji ovdje nije prikazan zbog rušenja programa i nekoliko pokušaja nemogućnosti postizanja ponovne funkcionalnosti navedenih programa (Burp odbija suradnju i blokira cijeli promet, Blind XPath explorer baca grešku, a WebGoat naravno ne radi zbog toga što Burp blokira cijeli promet). Dakle ako imate volje, vremena i živaca za igranje kombinacijom alata, sretno!

Dakle u izradi zadatka bili su korišteni sljedeći alati i dodaci:

I izvori:


--kmejas 00:06, 7. siječnja 2012. (CET)

SSI ubacivanje (SSI Injection)

SSI - Server Side Includes

SSI (eng. Server Side Includes) je skriptni jezik koji se izvršava na poslužitelju, a koristi za za izvršavanje operacijskih naredbi na sustavu ili pak uključivanje (prebacivanje) sadržaja iz jedne ili više datoteka na web stranicu koja se nalazi na nekom serveru. Najjednostavniji primjer takvog uključivanja je npr. funkcionalnost web stranice "dnevna ponuda". Kod za uključivanje takve datoteke na web stranicu bi izgledao ovako: 

<!--#include virtual="../ponuda.txt" -->

S promjenom "ponuda.txt" datoteke, sve stranice koje uključuju takvu datoteku će se prikazati najnoviju dnevnu ponudu. Uključivanje nije ograničeno samo na datoteke, a može uključivati i tekst koji kao izlaz generira neki program, ili pak vrijednost varijable sustava kao što je npr. trenutno vrijeme.

SSI su korisna i za recimo uključivanje zajedničkog djela web mjesta kao što su zaglavlje (eng. header), podnožje (eng. footer), kao i zajednički navigacijski meni.

Da bi web server prepoznao HTML datoteku s omogućenim SSI-jem, naziv datoteke bi trebao imati jednu od uobičajenih ekstenzija .shtml, .stm, .shtm ili pak postavljen izvršni bit datoteke, ako je server konfiguriran da dopušta takvo nešto.

SSI podržava samo text i kontrolni tok je poprilično jednostavan, moguć je odabir ali petlje nisu podržane osim ako se ne koristi rekurzija upotrebom "include" ili HTTP preusmjeravanjem.

Glavni tipovi web servera koji podržavaju SSI su Apache, nginx, lighttpd i IIS.

[39]

SSI omogućuje dodavanje dinamički generiranog sadržaj na HTML stranicu, bez potrebe za posluživanjem cijele stranicu putem CGI programa ili neke druge dinamičke tehnologije. [40]


Sintaksa SSI

SSI ima jednostavnu sintaksu. 

<!--#naredba parametar=vrijednost -->

Naredbe (eng. directive) su smještene u HTML komentare tako da ukoliko SSI nije omogućen, korisnici ni ne vide takav sadržaj, osim ako ne pogledaju izvorni kod stranice. [41]

Umetanje SSI naredbi u HTML dokument izgleda ovako: 

<!--#echo var="DATE_LOCAL" -->

<!--#include virtual="/cgi-bin/counter.pl" -->

<!--#include virtual="/zaglavlje.html" -->

<!--#exec cmd="ls" -->

[42] --kmejas 12:08, 6. siječnja 2012. (CET)

Definicija napada

SSI Injection je tehnika iskorištavanja slabosti na serverskoj strani na način da napadač šalje kod u web aplikaciju, a koji će se kasnije izvršiti lokalno od strane web servera. SSI Injection iskorištava slabost aplikacije zbog koje podaci nisu uopće ili dovoljno pročišćeni-filtrirani (eng. santinized) prije ubacivanja u HTML datoteku koju interpretira serverska strana.

Prije nego što da na raspolaganje HTML stranicu klijentu, web server može analizirati i izvršiti SSI izraze. U nekim slučajevima, web stranica ubacuje podatke dobivene od strane korisnika u sam izvorni kod stranice ( npr. oglasne ploče, knjige gostiju, CMS – sustavi za upravljanje sadržajem). Na taj način napadač može izvršiti proizvoljne naredbe operacijskog sustava ili pak uključiti sadržaj koji je zabranjen, što će se realizirati idući put kada stranica bude poslužena. Takav napad se odvija na razini ovlasti korisnika web servera.[43]

Primjer 1.

Sljedeće naredbe sadrže sintaksu koja se koristi za izvođenje OS naredbi. 

<!--#exec cmd="/bin/ls /" -->

< !--#exec cmd="ls" -->

< !--#exec cmd="dir" -->

< !--#exec cmd="cd C:\admin\dir">


Primjer 2.

Neki primjeri SSI-ja za pristupanje i promjenu informacija na serveru: 

<!--#echo var="DOCUMENT_NAME" -->

<!--#echo var="DOCUMENT_URI" -->

<!--#config timefmt="A %B %d %Y %r"-->

<!--#fsize file="ssi.shtml" -->

[45]

--kmejas 17:00, 6. siječnja 2012. (CET)

Provjera ranjivosti web stranice na SSI Injection

SSI napad dakle omogućuje iskorištavanje web aplikacija ubrizgavanjem skripte u HTML stranice ili izvršavanjem proizvoljnog koda na daljinu. To može biti izvršeno kroz manipulaciju SSI-jem koji se trenutno koriste ili pak kroz polje za korisnički unos.

Moguće je provjeriti da li program ispravno validira polja za unos podataka, umetanjem znakova koji se koriste u SSI naredbama (eng. directive), kao što su: 

<! # = /. "-> I [-ZA-Z0-9]

Drugi način da se provjeri da li je aplikacija ranjiva je prisutnost stranice sa nastavkom .stm, .shtm i .shtml. No ako takav format stranica i nije prisutan u sustavu to ne znači da aplikacija nije osjetljiva na SSI napad.

Važno je napomenuti da će aplikacija biti osjetljiva na takav oblik napada samo ako web server dopušta izvršenje SSI-jeva, a da prije uopće ili dobro ne provjerava/filtrira unešene podatke.

Napadač može pristupiti osjetljivim informacijama, poput datoteka s lozinkama te izvršiti shell naredbe (eng. shell commands). SSI naredbe se ubacuju u polja za unos i šalju se na web server. Web server razdvaja i izvodi naredbe prije nego što rezultate vrati na web stranicu. Na taj način će rezultati napada biti vidlljivi sljedeći puta kada se stranica učita u preglednik korisnika. [46] --kmejas 17:01, 6. siječnja 2012. (CET)

Gray Box testiranje

Ako imamo pristup do izvornog koda aplikacije možemo lako saznati:

  1. Ako se SSI naredbe koriste tada web server ima omogućenu podršku za SSI, što znači da je to potencijalni problem kojeg bi trebalo provjeriti.
  2. Gdje se obrađuju korisnički unosi, sadržaj cookieja te HTTP zaglavlja. Tada je brzo utvrđen potpun popis unosa.
  3. Kako se rukuje unosom, koji tip filtriranja se upotrebaljava, koje znakove aplikacija ne propušta i koliko tipova kodiranja se uzima u obzir.

Ovi koraci se uglavnom provode koristeći program za traženje stringova Grep. On pronalazi prave ključne riječi unutar izvornog koda (SSI naredbe, CGI varijable okruženja, varijable priduružene u korisnički unos, funkcije za filtriranje i sl.)

Black Box testiranje

Ovako ispitivanje je veoma slično onima koje se koriste za testiranje ostalih ranjivosti ubacivanjem koda. Da bi nastavili s takvom provjerom potrebno je zadovoljiti kriterije za Gray Box testiranje. Dakle, moramo naći svaku stranicu gdje je korisniku dopušteno/omogućeno unošenje podataka te zatim provjeriti da li program ispravno unosi podatke u sustav. Ako filtriranje podataka nije dovoljno dobro, potrebno je provjeriti da li sustav ispravno prikazuje podatke (nepromijenjene, npr. u poruci o pogrešci ili postu foruma).

Osim uobičajenih podataka unešenih od strane korisnika, uvijek je potrebno razmotriti ulazne vektore (HTTP zaglavlja zahtjeva i sadržaje kolačića) koji se mogu lako krivotvoriti.

Nakon što smo stvorili popis potencijalnih prijetnji, možemo provjeriti da li se ulazni podaci ispravno filtriraju te gdje se takvi podaci spremaju.

Trebamo se uvjeriti da možemo ubaciti znakove koji se koriste u SSI naredbama: 

< ! # = / . " - > and [a-zA-Z0-9]

Da bi se uvjerili da je filtriranje podataka nedovoljno dobro, možemo unijeti sljedeće u formu za unos: 

<!--#include virtual="/etc/passwd" -->

Ako je aplikacija ranjiva, naredba se ubacuje i interpretira od strane servera sljedeći puta kada se stranica poslužuje, što uključuje i sadržaj Unix datoteke s lozinkama.

Ubacivanje se može provesti preko HTTP zaglavlja, ako web aplikacija koristi te podatke za izgradnju dinamički generiranje stranice: 

GET / HTTP/1.0
Referer: <!--#exec cmd="/bin/ps ax"-->
User-Agent: <!--#include virtual="/proc/version"-->

[47] --kmejas 18:40, 6. siječnja 2012. (CET)

Alati za provjeru ranjivosti

Najpoznatiji alati za provjeru SSI ranjivosti su:

--kmejas 02:10, 6. siječnja 2012. (CET)

LDAP Injection

O LDAP-u

LDAP je skraćenica od eng. složenice Lightweight Directory Access Protocol i ime je za aplikacijski protokol za čitanje i pisanje imenika preko IP mreže. Imenik (ili direktorij) je u LDAPu datoteka ili skupina podataka koji su organizirani slično kao telefonski imenik, koji sadrže podatke o korisnicima, datotekama i aplikacijama, kao i njihove sigurnosne postavke. [48]


Servisi LDAP direktorija su aplikacije koji spremaju I organiziraju informacije sa zajedničkim atributima, gdje su te informacije strukturirane na temelju stabla zapisa imenika, a za njihovo pretraživanje koriste se vrlo efikasni mehanizmi pretraživanja. Usluga LDAP direktorija temelji se na klijent-server modelu. Jedan ili više LDAP servera sadrži podatke koji čine LDAP stablo direktorija ili LDAP bazu podataka. LDAP klijent spaja se na LDAP server I postavlja upit. Server nakon toga uz pomoć filtera pretražuje zapise u imeniku I vraća odgovor ili pokazivač gdje se tražena informacija nalazi (u većini slučajeva na drugome LDAP serveru). Jedna od glavnih značajki LDAP servisa jest globalni pristup I prikaz podataka – ako se klijent spoji na jedan od LDAP servera, vidjet će jednaku LDAP strukturu direktorija, te će imati jednak pristup kao I na nekom drugom povezanom LDAP serveru.[49]


Sam protokol koristi specifikacije X.500 DAP (Directory Access Protocol) protokola, na čijim principima I načelima je nastao. Informacije koje se najčešće spremaju u LDAP direktorije su podaci o korisnicima, aplikacijama, datotekama, printerima I ostalim resursima dostupnima putem mreže. [50]

--Nikola.baksa 14:12, 6. siječnja 2012. (CET)

Definicija LDAP injection napada

Većina današnjih web aplikacija koristi neku vrstu komponenata za unos korisničkih podataka, u svrhu generiranja dinamičkih zahtjeva. Naime, to predstavlja potencijalni rizik za zloćudnu manipulaciju kod slanja korisničkih zahtjeva prema serveru. U našem primjeru, LDAP upiti koje korisnik na pojedinoj web stranici prosljeđuje LDAP serveru, predstavljaju mogući rizik od napada, ukoliko preventivni sigurnosni mehanizmi nisu ugrađeni.


Ova tehnika napada bazira se na modificiranom korisničkom unosu podataka, koji se proslijeđuju LDAP serveru kao upit. Cilj ovog napada jest da se izmjeni semantičko značenje upita koji se izvršava na strani LDAP servera. Web stranica, u slučaju nepravilnog korisničkog unosa, može dozvoliti izmjenu LDAP naredbe, koja je inače transparentna I nedostupna korisniku. Time je moguće da se upit ili naredba izvršava s istim pravima koje ima izvršna komponenta (primjerice Web server, Database server itd). Ovaj način predstavlja veliki sigurnosni propust koji dozvoljava napadaču da modificira I manipulira svim objektima koji se nalaze unutar LDAP imenika. LDAP injection napadi jedna su vrsta napada umetanjem, vrlo slični SQL injection napadima. [51]


Uspješna eksploatacija LDAP injection napada omogućava napadaču:

--Nikola.baksa 11:42, 6. siječnja 2012. (CET)

Vrste LDAP injection napada

AND LDAP Injection

U ovoj vrsti napada, aplikacija uz normalan upit za pretraživanje LDAP direktorija prosljeđuje i "&" operator, te jedan ili više parametara definiranih od strane korisnika, primjerice: 

(&(parametar1=vrijednost1)(parametar2=vrijednost2))

gdje se uz pomoć vrijednost1 i vrijednost2 vrši pretraživanje u LDAP direktoriju. Napadač može zatim vrlo lako umetnuti svoj kod, uz uvjet da se drži pravila kod kreiranja filtera.

Zaobilaženje kontrole pristupa (Access Control Bypass)

Primjer ove vrste napada je tipična web stranica za prijavu koja sadrži 2 polja - Korisnik i Lozinka, gdje su Kor i Loz parametri koji sadrže vrijednosti navedenih polja i prosljeđuju se LDAP serveru u sljedećem upitu: 

(&(Korisnik=Kor)(Lozinka=Loz))

Ako bi napadač unio postojeće korisničko ime, primjerice mmaric, i umetnuo sljedeći izraz 

(&(Korisnik=mmaric)(&))(Lozinka=Loz))

LDAP server bi procesuirao samo prvi filter koji će uvijek biti istinit (TRUE), te bi napadač na ovaj način vrlo lako ušao u sustav bez potrebe za upisom pravilne lozinke (podrazumijeva se da bi napadač mogao za lozinku upisati bilo koji izraz). [53]

U slučaju da je upit za pretraživanje koncipiran tako da se vrijednost parametra pridružuje jednostrukim ili dvostrukim navodnicima, prethodni izraz mogli bismo napisati i na sljedeće načine: 

(&(Korisnik='mmaric')(&))(Lozinka=Loz))
(&(Korisnik="mmaric")(&))(Lozinka=Loz))
(&(Korisnik=\'mmaric\')(&))(Lozinka=Loz))
(&(Korisnik=\"mmaric\")(&))(Lozinka=Loz))

[54]

Povećanje ovlasti (Elevation of Privilages)

Kada govorimo o napadu povećanjem ovlasti preko LDAP-a , smatra se na promjenu ovlasti u autentikacijskoj strukturi spremljenoj u LDAP bazi podataka. Pojedini objekti koji se nalaze na serveru mogu imati definirane atribute koji prikazuju potrebnu razinu ovlasti za njihov prikaz ili promjenu, pa će prema tome korisnik s nedostatnim ovlastima imati zabranjen pristup u njihovom dohvaćanju / pregledu. Uzet ćemo za primjer da sljedeći upit prikazuje sve dokumente vidljive korisnicima s niskim ovlastima: 

(&(direktorij=dokumenti)(razina_ovlasti=niska))

gdje je dokumenti vrijednost prvog parametra, te niska vrijednost drugog parametra. Ako napadač želi vidjeti sve dokumente, uključujući i one koji su vidljivi samo korisnicima s visokom razinom ovlasti, može upotrijebiti umetanje sljedećeg koda: 

(&(direktorij=dokumenti)(razina_ovlasti=*))(&(direktorij=dokumenti)(razina_ovlasti=niska))

LDAP server će iz upita obraditi samo prvi filter (&(direktorij=dokumenti)(razina_ovlasti=*)), dok će drugi filter (&(direktorij=dokumenti)(razina_ovlasti=niska)) ignorirati. Kao rezultat, napadač će vidjeti sve dokumente dostupne za sve korisnike bez obzira na njihovu razinu ovlasti.

--Nikola.baksa 17:13, 6. siječnja 2012. (CET)

OR LDAP Injection

U ovoj vrsti napada, aplikacija uz normalan upit za pretraživanje LDAP direktorija prosljeđuje i "|" operator, te jedan ili više parametara definiranih od strane korisnika, primjerice: 

(|(parametar1=vrijednost1)(parametar2=vrijednost2))

gdje se uz pomoć vrijednost1 i vrijednost2 vrši pretraživanje u LDAP direktoriju. Napadač može zatim vrlo lako umetnuti svoj kod, uz uvjet da se drži pravila kod kreiranja filtera.

Otkrivanje informacija (Information Disclosure)

Napadaču su svakako vrlo važne informacije i o resursima koji se koriste u organizaciji koju planira napasti, a preko napada otkrivanjem informacija, vrlo lako može doći do ključnih saznanja koja mu mogu koristiti u daljnjim napadima.

Na primjeru pretraživača resursa, možemo vidjeti kako napadač uz pomoć sljedećeg izraza 

(|(tip=printer)(tip=skener))

može vidjeti sve uređaje u sustavu koji su tipa printer i skener. Uz ove informacije, napadač može dohvatiti još povjerljivih informacija, kao primjerice koji sve korisnici koriste spomenute resurse 

(|(tip=printer)(uid=*))(type=skener))

[55]

Reduciranje mogućih znakova (Charset reduction)

U ovoj metodi napada, cilj je napadača da odredi (pogodi) valjane znakove koji tvore vrijednost svojstva nekog objekta. Napadač uz pomoć zamjenskih znakova (znak * primjerice) i nasumično odabranih znakova pokušava u više koraka pokušava odrediti vrijednost nekog objekta. U svakom koraku koji je uspješan za napadača, smanjuje se broj mogućih znakova, čime se povećava šansa da nakon konačnog broja koraka pronađe traženu vrijednost. Uzmimo za primjer da napadač pokušava odrediti naziv zone u kojoj će moći vidjeti povjerljive podatke vezane uz osobu imena Karlo za stranicu 

http://testserver.com/traženje_osoba.aspx?ime=Karlo(zona=b*)

Kako je nakon prvog pokušaja napadač uvidio da naziv zone ne započinje sa imenom b, nasumičnim odabirom pokušava odrediti kojim slovom započinje naziv zone, dok nakon nekoliko pokušaja ne utvrdi da za početno slovo p (zona=prv) 

http://testserver.com/traženje_osoba.aspx?ime=Karlo(zona=p*)

Dobiva tražene podatke o osobi 

ime:Karlo
prezime: Knapić
adresa: Ulica Kralja Zvonimira 23 Zagreb
telefon: 01/222-333-444
[56]

Promjena informacija (Information Alteration)

LDAP protokol uz operacije pretraživanja, omogućuje i operacije dodavanja, promjene ili pak brisanja informacija preko dostupnih API kontrola u web aplikacijama. Preko polja za unos korisničkih podataka, napadač može umetnuti svoj kod, te tako obrisati ili promijeniti određene podatke. PHP jezik sadrži već gotove funkcije pomoću kojih se može manipulirati sa LDAP podacima, a jedna od njih je i 

bool ldap_modify(resource $LDAP_link, string $zapis_za_izmjeniti, array $novi_podaci);

u kojoj ako napadač za parametar $zapis_za_izmjeniti upiše uid=*, u tom slučaju će se svi zapisi ažurirati na vrijednost parametra $novi_podaci. Na jednak način moguće je izvršiti manipulaciju i sa ovim funkcijama: ldap_mod_replace(), ldap_mod_del(), ili ldap_delete.

--Nikola.baksa 05:07, 6. siječnja 2012. (CET)

Blind LDAP Injection

Napadač može presresti odgovore LDAP servera, no iako aplikacija ne prikazuje poruke o greškama, umetnuti kod u LDAP filteru može generirati ispravan odgovor (TRUE) ili pak grešku (FALSE). Na ovaj način, napadač može "pingati" server s ciljem dobivanja istinitih ili neistinitih odgovora, što se smatra Blind LDAP napadima. Ovakva vrsta napada sporija je od tipičnih napada, no može biti vrlo efikasna jer se temelji na binarnoj logici.

AND Blind LDAP injection

Pretpostavimo da želimo vidjeti sve Epson printere koji su spojeni na LDAP sustav/mrežu. U tom slučaju prema LDAP serveru poslali bismo sljedeći upit 

(&(objectClass=printer)(type=Epson*))

gdje bismo dobili prikazane sve ikone Epson printera ako oni postoje (TRUE vrijednost). Ako pak ne postoji nijedan Epson printer na mreži, odgovor sa servera bio bi FALSE i ne bismo vidjeli nijednu ikonu. Prema ovom principu napadač može umetnuti svoj kod, te provjeriti bilo koju informaciju iz LDAP imenika. Jedan primjer napada mogao bi biti sljedeći: 

(&(objectClass=*)(objectClass=resources))(&(objectClass=users)(type=Epson*))

Napadač na ovaj način može pristupiti i ostalim objektima u LDAP imeniku, kao što su primjerice korisnici, ako odgovor sa servera vraća TRUE (ako barem jedna ikona printera prikazana, objectClass će također biti TRUE).

OR Blind LDAP injection

OR Blind LDAP injection napad, sličan je AND Blind injection napadu. Razlikuju se u operatorima, gdje se umjesto "&" znaka, u ovoj vrsti napada koristi OR operator "|". Tipičan primjer ovog napada mogao bi izgledati ovako: 

(|(objectClass=void)(objectClass=resources))(&(objectClass=void)(type=Epson*))
Otkrivanje atributa (Discovering Attributes)

Uz pomoć gore navedene "AND Blind LDAP injection tehnike", napadač može iskoristiti AND operator prilikom pokušaja pronalaska mogućih atributa u upitima koji se prosljeđuju LDAP serveru. Ukoliko napadač umetne kod i pošalje primjerice, sljedeći zahtjev prema serveru 

(&(idPrinter=HPLaserJet2100)(ipAddress=*))(objectClass=printer))

može saznati, tj. pogoditi naziv atributa, ukoliko mu server vrati podatke (TRUE). U slučaju da odgovor od servera na upit ne sadrži podatke, napadač ponovnim nasumičnim odabirom naziva atributa može provjeravati i pogađati točan naziv atributa.

--Nikola.baksa 14:12, 6. siječnja 2012. (CET)

Metode i tehnike prevencije LDAP napada

Svi napadi koje smo naveli u prethodnim odlomcima, realizirani su na aplikacijskome sloju, što znači da firewall i ostali mehanizmi provjere upada na sloju mreže, neće biti u mogućnosti spriječiti bilo koji od ovih napada. Međutim, primjenom određenih mehanizama kao što su "obrambeno programiranje", sofisticirana provjera korisničkog unosa (sa serverske strane), dinamičke provjere (na strani klijenta) i primjena preporučenih sigurnosnih mehanizama kod LDAP protokola, mogu značajno utjecati na smanjenje mogućih propusta kod slanja LDAP upita. [57]

Provjera korisničkog unosa

Vrlo je važno spriječiti mogući unos malicioznog koda što je prije moguće, a jedna od metoda koja nam u tome može pomoći, jest dinamička provjera korisničkog unosa na strani klijenta uz pomoć JavaScripta provjere i "Regular Expressions" izraza na serverskoj strani. Korisnik prilikom unosa znakova u pojedino polje, može biti upozoren "user-friendly" porukom o nedozvoljenom unosu znakova, čime se smanjuje i mogućnost pojavljivanja "unhandled" grešaka kod unosa specifičnih znakova.

LDAP konfiguracija

Implementacija robusnih kontrola pristupa podacima na LDAP direktoriju je imperativ, osobito kada govorimo o postavljanju prava na korisničkim objektima, te javno dostupnim resursima. Važno je u što većoj mjeri izbjegavati uporabu uIDNumber parametra kod LDAP upita, u svrhu što većeg smanjenja sigurnosnog rizika kod promjene pristupnih prava. Također, poželjno je da LDAP server ne bude direktno vidljiv na Internetu, već da se nalazi u izoliranoj okolini.

--Nikola.baksa 14:12, 6. siječnja 2012. (CET)

Alati

Za kraj, naveo bih neke od poznatijih alata pomoću kojih možemo ispitati sigurnost web aplikacije na način da se simuliraju LDAP napadi i provjeravaju potencijalni sigurnosni propusti:

[64] --Nikola.baksa 13:48, 6. siječnja 2012. (CET)

CRLF Injection

Definicija CRLF-a

Pojam CRLF (eng. CR=Carriage Return, LF=Line Feed) predstavlja oznaku za kraj retka teksta. Sastoji se od kombinacije dva ACSII znaka koji se ne prikazuju na ekranu, ali se vrlo često koriste kod operacijskih sustava Windows. Na operacijskim sustavima Linux/UNIX kraj retka označava se samo korištenjem ACSII znaka Line Feed.

Kombinacija tih znakova koristi se kod pritiskanja tipke „Enter“ na tipkovnici. Ovisno o aplikaciji koja se upotrebljava, pritiskanje te tipke obično označava početak novog retka ili slanje neke naredbe. [65]


CR i LF kombinacija znakova može se u literaturi naići u nekoliko oblika, ovisno o uporabi i prikazu (ASCII kod znakova, prikaz u nazivima web stranica, prikaz u programskim jezicima): 

CR (Carriage Return) = ASCII 13 = %0d = \r
LF (Line Feed)       = ASCII 10 = %0a = \n

CRLF predstavlja značajan niz znakova za programere. Ova 2 specijalna znaka predstavljaju marker za kraj retka (End of Line - EOF) za mnoge Internetske protokole kao što su MIME (email), NNTP (newsgrupe), te najvažniji - HTTP. Kada programeri pišu kod za web aplikacije, oni razdvajaju zaglavlja na temelju pozicije gdje se nalazi CRLF. Ukoliko je napadač u mogućnosti da umetne svoju CRLF sekvencu u HTTP zahtjev, omogućena mu je maliciozna kontrola načina na koji se web stranica prikazuje. [66] --Nikola.baksa 00:02, 13. siječnja 2012. (CET)


CRLF injection napad

CRLF injection napad se događa kada napadač umeće CRLF naredbe u sustav. Ova vrsta napada nije tehnološki sigurnosni propust u operacijskom sustavu ili poslužitelju, nego ovisi o načinu na koji je web stranica razvijena. Vrlo često nepažnjom ili neznanjem razvojnih programera nastaju ranjive web aplikacije koje zlonamjerni korisnici iskorištavaju za umetanje CRLF naredbi. [67]


CRLF napadi nisu poznati u tom mjeri kao ostali injection napadi, no kada se koriste na ranjivim aplikacijama, njihovi učinci mogu biti snažni i devastirajući. Dakle, iako se radi zapravo o vrlo jednostavnome napadu, on svakako može predstavljati vrlo moćan web napad. Kod nekih izvora, CRLF napadi poznatiji su pod nazivom HTTP Response Splitting, tj "Cijepanje HTTP odgovora". Ovaj način napada zapravo daje mogućnost napadaču da slanjem jednog HTTP zahtjeva prema web serveru, dotični interpretira kao dva zasebna HTTP zahtjeva, umjesto jednog. Web server nakon toga šalje dva HTTP odgovora, te u tom slučaju drugi HTTP odgovor bude kontroliran od strane napadača.

Najčešća uporaba CRLF napada jest da se prvobitni HTTP odgovor web servera poništi, te se pritom generira drugi HTTP odgovor, koji je neplaniran (sama aplikacija ga nije tražila) i pod utjecajem napadača. Ovakav napad, vrlo je lako ostvariti ako aplikacija ugrađuje neprovjerene korisničke podatke kod preusmjeravanja ili kod definiranja cookie-a. [68]

Kada napadač pronađe web aplikaciju ranjivu na CRLF injection napad, mogućnost iskorištavanja ovisi o njezinoj strukturi i slabostima.

Kako će određeni nedostatak djelovati na web stranicu ovisi o tipu web stranice. Određeni nedostatak može značajno ugroziti sigurnost jedne web aplikacije, dok za drugu on može predstavljati sasvim nebitnu pogrešku. Sve ovisi o tome omogućuje li korisnicima upravljanje web aplikacijom. [69] --Nikola.baksa 00:02, 13. siječnja 2012. (CET)

Primjeri CRLF injection napada

Ranjivost sustava za objavljivanje poruka

Za prikaz prve metode CRLF injection napada, uzet ćemo jednostavan primjer aplikacije za objavljivanje poruka koji je podložan CRLF napadima. Pretpostavimo da je trenutno stanje objavljenih poruka sljedeće: 

8/04/07 - Dave:Something is wrong with the login system?
09/04/07 - haZed:Yeah, you should fix it....

Obje navedene poruke su legitimne, no napadač može iskoristiti ranjivost sustava i pokušati objaviti poruku koja će izgledati kao da ju je poslao administrator. Da bi izveo napad, unijet će sljedeće u polje za unos: 

Yep, doesn't work..\n10/04/07/ - Admin: I've relocated the login to http://attackersite.com/login.php, you should be able to login there.

Nakon toga, rezultat objave komentara, tj. poruke na sustavu, izgledat će sljedeće: 

8/04/07 - Dave:Something is wrong with the login system?
09/04/07 - haZed:Yeah, you should fix it....
09/04/07 - Ethernet:Yep, doesn't work..
10/04/07 - Admin: I've relocated the login to http://attackersite.com/login.php

Kao što je i vidljivo iz primjera, napadač će izvedbom ovakog CRLF injection napada (unosom \n znaka koji će automatski locirati kursor u novome retku), biti u mogućnosti predstaviti se kao Administrator i pribaviti korisničke podatke za prijavu na malicioznoj stranici koja se nalazi u linku.

Ranjivost kod e-mail formi

Drugim primjerom pokazat ćemo kako je moguće poslati email drugim korisnicima, uz mogućnost skrivanja adrese samog pošiljatelja, što se može koristiti kod spama-anja tuđih mail pretinaca. Da bi se iskoristila spomenuta ranjivost, u Naslovu (Subject) e-maila dodat ćemo sljedeće: 

Hey, it's Dave\nBcc: dave@email.com

Ovim napadom, poslat ćemo mail na Bcc adresu dave@email.com (zbog \n znaka Bcc će se prosljediti u novome redu kao zasebni parametar), kao i osobi koju smo naveli kao primatelja. Dodavanjem nekoliko mail adresa na ovaj način, moguće je anonimno poslati spam mailove, bez otkrivanja identiteta pošiljatelja. [70]

Ranjivost kod POP3 i NNTP protokola

Poznato je da POP3 protokol koristi naredbe RETR X za dohvaćanje nepročitanih email poruka, te DELE x za brisanje poruka. Naime, ako email klijentski program koristi sljedeći oblik naredbe za dohvaćanje novih e-poruka: 

RETR $msg\r\n

te se za $msg varijabla ne vrši CRLF provjera, moguće je u jednom koraku pročitati jednu email poruku (RETR 1), te obrisati drugu email poruku (DELE 2), ako $msg varijabla poprimi sljedeću vrijednost: 

1\r\nDELE 2

Na ovaj način, nakon čitanja poruke, varijabla $msg dat će instruckciju da se u istome koraku izvrši i brisanje druge poruke, čime bi se naredbe zapravo tumačile na ovaj način: 

RETR 1
DELE 2

Na identičan način, kod NNTP protokola prilikom dohvaćanja postova, u istoj naredbi mogli bismo izvršiti i naredbu objavljivanja posta, primjerice: 

ARTICLE 1\r\nPOST 2

[71]

HTTP Splitting napad

Poznato je da neke web stranice koriste dio korisničkog unosa prilikom generiranja vrijednosti headera i njihovih odgovora. Najpoznatiji primjeri jesu HTTP redirekcije ili preusmjeravanja, prilikom čega ciljana URL adresa sadrži neke od korisničkih parametara. Uzet ćemo za primjer stranicu gdje se od korisnika traži odabir standardnog ili naprednog web sučelja. Korisnikov odabir bit će prosljeđen kao parametar u zaglavlju odgovora prilikom preusmjeravanja na odabranu stranicu. Ukoliko korisnik odabere napredno sučelje, parametar interface imat će vrijednost advanced, što će generirati sljedeće odgovor: 

HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http://victim.com/main.jsp?interface=advanced

Kada preglednik primi ovaj HTTP odgovor, preusmjerit će korisnika na stranicu koja se nalazi u Location zaglavlju. No, u slučaju da aplikacija ne filtrira korisnički unos, moguće je da se u interface parametar umetne slijed %0d%0a koji predstavlja CRLF slijed znakova za prelazak u novi red. U nastaloj situaciji, aktivirat ćemo odgovor koji će biti interpretiran kao dva odvojena odgovora, te u slučaju da koristimo web proxy, moguće je zaraziti web cache koji će kasnije prosljeđivati krivi sadržaj svim korisnicima koji ga zatraže. Ovaj sprecifičan napad naziva se još i web cache poisoning. Za demonstriranje napada, uzet ćemo da je napadač umetnuo sljedeći kod umjesto parametra interface: 

advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>

Odgovor koji ćemo dobiti od napadnute stranice je sljedeći: 

HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http://victim.com/main.jsp?interface=advanced
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 35

<html>Sorry,%20System%20Down</html>

Web cache će nakon toga vidjeti 2 različita odgovora, te ako napadač odmah iza prvog zahtjeva pošalje drugi zahtjev kojim će tražiti /index.html, web cache će povezati taj zahtjev sa sljedećim odgovorom i cache-irati njegov sadržaj, pa će svi sljedeći direktni zahtjevi na victim.com/index.html primiti poruku System down. Na ovaj način, napadač može preusmjeriti web site za sve korisnike koji koriste web cache na proxyu. Umjesto ovog napada, napadač je mogao umetnuti Javascript kod i uz pomoć njega "ukrasti" korisnikove cookie podatke. Važno je da se zaglavlja Location i Set-Cookie kao najčešća meta napada provjeravaju zbog mogućih ranjivosti. [72] --Nikola.baksa 00:02, 13. siječnja 2012. (CET)


Zaštita od CRLF napada

Najbolji način provjere ranjivosti web stranice i aplikacija na CRLF injection napad je uporabom skenera web ranjivosti. On će pretraživanjem cijele Vaše web stranice automatski ispitati ranjivost na CRLF napad. Po završetku skeniranja naznačiti će ranjive URL lokacije i skripte te javiti kako se navedena ranjivost može jednostavno popraviti. [73]

Provjera pomoću koje se web stranica može zaštiti od CRLF napada je sljedeća: 

if (eregi('n', $_POST['input'])) //Provjera znaka za novu liniju kod POST varijable
//start if..
die("CRLF Attack Detected"); //izlaz iz programa u slučaju da se CRLF nađe u varijalbi
 //end if..

--Nikola.baksa 00:02, 13. siječnja 2012. (CET)

Aplikacije za učenje/testiranje ranjivosti

Postoji nekoliko web aplikacija koje služe u svrhu učenja i testiranja svih ranjivosti. Neke od njih su navedene niže i slobodne su za korištenje. Neke od njih se koriste u praktičnom dijelu, u idućem poglavlju.

Mutillidae je slobodna, open source web aplikacija i može biti instalirana na Linux, Windows XP i Windows 7 pomoću XAMMP što ju čini vrlo jednostavnom za korištenje. Mutillidae sadrži desetke ranjivosti i savjete za pomoć korisniku kako ih upotrijebiti. Aplikacija je namjerno napravljena da bi služila kao alat za vježbanje, pen-testing/hakiranje web aplikacija, upotrebom raznih ranjivosti i sadrži sve ranjivosti specificirane u Owasp Top 10 ranjivosti.


WebGoat je namjerno nesigurna J2EE web aplikacija dizajnirana za učenje (ne)sigurnosti web aplikacija. U svakoj lekciji, korisnici trebaju pokazati svoje razumijevanje sigurnosnog problema na način da iskoriste pravu ranjivost WebGoat aplikacije. Na primjer, u jednoj od lekcija korisnik mora koristiti SQL Innjection za krađu lažnih brojeva kreditnih kartica. Aplikacija je realno nastavno okružje, pružajući korisnicima savjete i kodove za bolje objašnjenje same lekcije.


DVWA je PHP / MySQL web aplikacija koja je jaaako ranjiva :). Glavni ciljevi su joj legalno testiranje vještina i alata. Služi kao pomoć stručnjacima za sigurnost, web programerima za bolje razumijevanje procesa osiguranja web aplikacija, ali i kao pomoć nastavnicima / studentima za učenje u sigurnom okruženju..i svima ostalima :)

--kmejas 15:50, 6. siječnja 2012. (CET)

Umetanje naredbi (Command injection)

Po OWASPu svrha napada umetanjem koda je ubaciti ih u nezaštićenu aplikaciju i izvršiti naredbe. Aplikacija se ponaša kao system shell i programski kod koji se ubacuje ima na raspolaganju privilegije system korisnika. Većina takvih napada su moguća radi nedostatka validacije nad podacima (polja formi, cookies, HTTP headers) koje napadač iskorištava.

Postoji više vrsta ubacivanja naredbi: SQL injection, Hibernate Query Language (HQL), LDAP, Xpath, Xquery, XSLT, HTML,XML, i OS command injection. OS command injecting je slučaj kada se izvršavaju sustavske naredbe kroz nezaštićenu aplikaciju na sistemskoj razini. Aplikacija se smatra nezaštićenom od OS umetanja naredbi ako je moguće doprijeti do sistemske razine OS.

Umetanje naredbi se u većini slučajeva odnosi na stavljanje sustavskog delimitera (npr. ';' ) u string/varchar argument funkcije i jednog ili niza system naredbi nakon njega. Školski primjeri:


Primjer 1 

int main(char* argc, char** argv) {
               char cmd[CMD_MAX] = "/usr/bin/cat ";
               strcat(cmd, argv[1]);
               system(cmd);
       }

Izvor: Članak: Command Injection; Example 2 (https://www.owasp.org/index.phpćommand_Injection). Preuzeto 02.02.2012.

Budući da se program vrti s root privilegijama, poziv system() se također izvršava u toj okolini. Tijekom normalnih, očekivanih pozivanja koda (s nazivom datoteke kao argument) kod funkcionira kako je planirano. Ako korisnik umjesto naziva neke datoteke upiše nešto poput ';rm –rf', system() nailazi na ';', ne dobije argument potreban za izvršenje programa, zaustavljuje program i nakon toga se izvršava kod koji slijedi nakon ';', u ovom slučaju 'rm –rf' . Primjer pokazuje ozbiljnost problema, tj. štetu koju je moguće nanijeti.


Mogući slučajevi ubacivanja naredbi:


Posljedice:


Moguće pomoći:


Validacija se može sastojati od duljine polja, tipa inputa, raspona inputa, nedostatka ili viška, sintakse, konzistentnosti na razini više polja i na razini poslovnih pravila app.


Primjer 2: Mozilla mailto protokol Mozilla ne validira input koji prenosi vanjskim URL protokol servisima/aplikacijama koje omogućava ubacivanje argumenata tim vanjskim servisima/aplikacijama. Sav softver koji radi na Mozilla platformi je ugrožen: Firefox, Thunderbird i Netscape, XULRunner aplikacije.


--Ivana.prpic 22:59, 26. kolovoza 2012. (CEST)

OS command injection

Umetanje naredbi s obzirom na podsustav na koji utječe može biti

Kod OS command injecting je naglasak na komunikaciji između aplikacije i operacijskog sustava. Aplikacija u biti koristi funkcije operacijskog sustava. Java primjerice koristi runtime objekt (java.lang.Runtime), .NET korist System.Diagnostics.Process.Start, PHP: exec() ili passthru(). Kategorizacija OS umetanja koda nije riješena, neki je svrstavaju pod injection flaws/mane, drugi pod validacije inputa, umetanje argumenta.. Ubacivanje koda se ne odnosi samo na text box polja formi web aplikacija. Uključena su i list/select boxes, check boxes, hidden polja, cookies, HTTP headeri, parametar names i values i drugi.


Metode detekcije:

  1. Jedan od načina zaštite je detekcija moguće slabosti web aplikacije automatiziranim (statičkim) analitičkim alatima. Mnogo današnjih alata koriste analizu toka podataka (data flow analysis) ili tehnike ograničavanja (constraints) da bi se smanjila opasnost. Automatizirana (statička) analiza možda ne/ce detektirati kada je pravilno izvršena input validacija zbog čega bi moglo doći do lažnih upozorenja.
  2. Postoji i automatizirana dinamička analiza koja vodi interakciju s programskim kodom koristeći test suites s različitim inputima poput fuzz testing (fuzzing), testiranje robustnosti i testiranja mana (fault).
  3. Ručna statička analiza se odnosi na ručne white box tehnike koje dodatno smanjuju broj mogu/cih ranjivosti. Smatra se da najefikasnijom metodom od navedene tri.


Da bi se smanjila ugroženost operacijskih sustava postoji više natuknica kojih bi se programeri mogli pridržati:

  1. Savjetuje se korištenje biblioteka operativnog sustava što je više mogu/ce i izbjegavanje korištenja vanjskih procesa
  2. Osiguravanje zatvorene okoline oko operativnog sustava i procesa tijekom izvršavanja procesa što bi moglo ograničiti nad kojim datotekama i/ili putanjima se dopušta manipuliranje ili koje naredbe programski kod/softver smije izvršavati. Primjerice Unix chroot jail, AppArmor ili SELinux . Java.io.FilePermission u Java SecurityManager-u omoguc/ava pisanje restrikcija nad datotečnim operacijama.
  3. Identificirati i smanjiti mogu/ce ulaze u sustav: za sve podatke koji se koriste za generiranje naredbi se savjetuje da ostane što je više mogu/ce unutar sustava, da vanjski procesi ne mogu doprijeti do njih. Primjer je spremanje podataka lokalno u sesiju (session), umjesto slanja podataka u skriveno polje forme.
  4. Duplicirati svaku sigurnosnu provjeru koja se izvodi na klijentskoj strani i na serverskoj strani također da bi se osiguralo zaobilaženje sigurnosti na klijentskoj strani što ostavlja server ranjivim .
  5. Ako je potrebno koristiti dinamički generirane upite nad bazom ili naredbe unatoč riziku, potrebno je pravilno označiti argumente i izbjegavati specijalne znakove. Najbolji, konzervativni pristup je filtrirati ili ukloniti sve znakove argumenta koji ne udovoljavaju bijeloj listi (white list) dozvoljenih znakova (primjerice samo alfanumerički znakovi ili znakovi) .
  6. Parametrizacija: ako postoji savjetuje se korištenje strukturiranih mehanizama koji razdvajaju podatke i programski kod. Ti mehanizmi bi se trebali pobrinuti za enkodiranje i validacije umjesto developera.
  7. Validacija inputa: Whitelist (bijela lista) ili 'prihvatiti samo poznato' smatra se najboljom strategijom za validacije inputa. Odnosi se na popis samo prihvatljivih znakova/riječi koji prolaze potrebnu specifikaciju. Znakovi/riječi koje whitelist ne prihvati se mogu odbaciti ili izmjeniti da bi naknadno odgovarali whitelisti. Iako se smatra boljom metodom od blackliste i blacklista ima svoje prednosti. Kod validacije inputa moguc/e je mnogo karakteristika uzeti u obzir: duljina, vrsta inputa, raspon dopuštenih znakova, nedostajuc/i ili viška znakovi, sintaksa, konzistentnost kroz povezana polja i usklađenost s poslovnim pravilima.
  8. Konverzija: kad je limitiran i poznat raspon vrijednosti poput naziva datoteka ili URLova, moguc/e je mapiranje, povezivanje ključeva s tim vrijednostima te sve vrijednosti koje ne postoje među tim ključevima se odbacuju.
  9. Error poruke i logovi trebaju dati dovoljno informacija o erroru, ali s druge strane ne smiju odati previše. Informacije o OS procesima i naredbama bi trebale ostati skrivene.
  10. Izvršavanje naredbi na najniže moguc/oj razini. Ako se naredbe mogu izvršavati bez administratorskih prava, preporučljivo je da se tako i izvršavaju.


Java primjer Klasa prihvaća input HTTP requestom. Klasa izvršava .exe datoteku na app serveru i vraća rezultat: 

public class DoStuff {
public string executeCommand(String userName)
{	try {
		String myUid = userName;
		Runtime rt = Runtime.getRuntime();
		rt.exec("doStuff.exe " +”-“ +myUid); // Call exe with userID
	}catch(Exception e)
		{
e.printStackTrace();
		}
	}
}

Metoda executeCommand poziva doStuff.exe koristeći runtime. Ne postoji validacija nad parametrom zbog čega OS postaje ranjiv. Dodavanjem amperstampa u parametar moguće je ubacivanje i izvršavanje naredbi u Osu. Primjer je netstat u javi ili '; cat /...' na UNIXu.

--Ivana.prpic 23:00, 26. kolovoza 2012. (CEST)

Praktični dio - ModSecurity

ModSecurity je vatrozid za web app-ove. Služi kao eksterni zaštitni sloj za detekciju i/ili prevenciju napada prije nego stignu do app. Štiti od više tipova napada, nadzire HTTP promet i provodi real-time analizu. Logira kompletne HTTP transakcije (zahtjeve i odg).

  1. HTTP Logging prometa - Većina servera ne bilježe request body-e zbog čega se većina napada pazira na POST request-ima. ModSecurity bilježi cijele request-ove i ovisno o želji, mogu se polja zamaskirati prije nego se zapišu.
  2. Real time nadzor i detekcija napada - ModSecurity nadzira HTTP promet u realnom vremenu da bi presreo napade. Tako se može reagirati na sumnjive događaje u web sustavu.
  3. Prevencija napada i virtualni patching - ModSecurity može promptno reagirati i spriječiti napade prije nego dođu do web aplikacija. Napravljena su 3 mehanizma koji postižu ovo: Negativni model sigurnosti koji nadzire request-ove tražeći anomalije i neobična ponašanja te standardne napade, Pozitivni model sigurnosti koji prihvaća samo request-ove koji su poznati, sve ostale odbija. Za to je potrebno poznavati web aplikacije koje treba zaštiti i poželjno je što manje ažurirati web aplikaciju i Poznate slabosti- virtualni patching omogućuje privremeno patchiranje izvan aplikacije , bez ažuriranja samog izvornog koda aplikacije i bez pristupa njemu dok se ne naprave pravi patch-evi na aplikaciji
  4. Fleksibilni sustav pravila - Implementira ModSecurity jezik pravila (Rule Language) koji služi učvršćivanju validacije protokola i otkrivanju čestih sigurnosnih problema.
  5. Embedded mode - ModSecurity je moguće ugraditi u postojeći firewall web aplikacije i njezine infrastrukture.
  6. Portabilnost - Sustav je moguće koristiti na svim platformama.


OWASP ModSecurity Core Rule Set (CRS)Project su poslovna pravila kao npr.:

  1. HTTP zaštita – detektiranje kršenje HTTP protokola
  2. Zaštita od čestih web napada
  3. Detekcija automatizacije – otkrivanje botova, skenera i sličnih malicioznih aktivnosti
  4. Zaštita od trojanaca
  5. Skrivanje error poruka sa strane servera

--Ivana.prpic 23:00, 26. kolovoza 2012. (CEST)

Praktični dio

 In progress :D

--kmejas 15:52, 6. siječnja 2012. (CET)

Literatura

SQL Injection


Xpath Injection

SSI Injection


LDAP Injection

CRLF Injection

Umetanje naredbi (command injection)

OS command injection

ModSecurity

Podjela zaduženja po poglavljima

Dario Huzjak - 1-4;

Kristina Mejaš - 5, 6 , 9;

Nikola Baksa - 7, 8;

Ivana Prpić

Dobavljeno iz "https://security.foi.hr/wiki/index.php/OWASP_Top_10:_Problemi_sa_umetanjem_koda/znakova"
Osobni alati
Imenski prostori
Inačice
Radnje
Orijentacija
Traka s alatima