3. Sigurnost Web aplikacija

Današnja slika Interneta dosta se razlikuje u odnosu na rane dane Interneta. U početku Internet se većinom sastojao od podatkovnih informacijskih repozitorija koji su većinom sadržavali statičke Web stranice. Cijeli sadržaj repozitorija bio je otvoren javnosti i Web preglednici su se jedino koristili kako bi se pristupilo tom sadržaju. Prijenos bitnih podataka bio je jednosmjeran, od Web poslužitelja prema korisniku. U većini slučajeva nije bilo autentifikacije korisnika, jer nije bilo potrebe za autentifikacijom. Svi su se korisnici tretirali jednako i svi su imali pristup istim podacima. U to vrijeme sigurnosni propusti su se uglavnom nalazili u samom Web poslužitelju. Napadači kompromitiranjem takvog Web poslužitelja uglavnom nisu dolazili do nekih novih povjerljivih podataka, jer su već svi podaci koji su se nalazili na poslužitelju bili javno dostupni.

Sadržaj Interneta se od tada znatno promijenio. Danas je većina Web stranica u biti aplikacija – Web aplikacija. Web aplikacije su u potpunosti funkcionalne aplikacije i ne razlikuju se od običnih korisničkih aplikacija. Za razliku od prije, prijenos bitnih podataka danas je dvosmjeran, od Web poslužitelja prema korisniku, ali i od korisnika prema Web poslužitelju. S Web aplikacijama danas se ostvaruju mnoge korisne radnje. One omogućuju registriranje i prijavu korisnika, provođenje bankovnih transakcija, kupovinu preko Interneta, pretraživanje sadržaja, objavljivanje vlastitog sadržaja i još puno toga. Većinom sadržaj koji Web aplikacija prezentira korisniku generira se dinamički i usklađen je sa zahtjevom koji je korisnik uputio aplikaciji. Velika većina informacija koje se procesiraju unutar Web aplikacija su privatne i jako osjetljive informacije. Zbog toga je sigurnost Web aplikacija danas ključno pitanje računalne sigurnosti, jer se radi s povjerljivim i osjetljivim podacima kojima neautorizirane osobe ne smiju imati pristup.

U nastavku su opisani temeljni zaštitni mehanizmi koji se koriste kako bi se Web aplikacije zaštitile od napadača i kako bi se spriječilo pojavljivanje ranjivosti. Nakon što se opišu zaštitni mehanizmi, opisati će se najčešće i najkritičnije ranjivosti Web aplikacija.

3.1 Temeljni zaštitni mehanizmi

Kako bi Web aplikacija bila sigurna potrebno je ugraditi nekoliko zaštitnih mehanizama. Sve Web aplikacije ugrađuju zaštitne mehanizme koji su konceptualno slični, ali detalji ugradnje, dizajn i efikasnost mehanizama dosta se razlikuju od aplikacije do aplikacije.

Neki od temeljnih zaštitnih mehanizama koji su ugrađeni u većini Web aplikacija su:

• kontrola korisničkog pristupa,
• kontrola korisničkog unosa,
• odgovor na napad na sigurnost Web aplikacije i
• održavanje Web aplikacije. [10]

Ovi zaštitni mehanizmi osnovna su zaštita Web aplikacija od zlonamjernih korisnika, napadača. Različite vrste napada koriste se kako bi se zaobišli ovi zaštitni mehanizmi koristeći različite ranjivosti unutar Web aplikacija. Ranjivosti u bilo kojem od ovih mehanizama, posebno u kontroli korisničkog pristupa i kontroli korisničkog unosa, obično vode do kompromitiranja Web aplikacije. Ranjivosti u ovim mehanizmima napadačima obično omogućavaju pristup povjerljivim podacima, provođenje nekih neautoriziranih radnji, ubacivanje proizvoljnog koda, izvršavanje sistemskih naredbi i sl. U nekim slučajevima kompromitiranjem Web aplikacije kompromitiran je i sustav na kojem se nalazi Web aplikacija. Zbog toga je poželjno razumjeti kako rade ti osnovni zaštitni mehanizmi kako bi se razumjeli i napadi na sigurnost Web aplikacija, i kako bi se razumjela sigurnost Web aplikacija općenito.

3.1.1 Kontrola korisničkog pristupa

Kontrola korisničkog pristupa funkcijama i podacima Web aplikacije potrebna je kako bi se neautoriziranim korisnicima spriječio pristup osjetljivim informacijama. Ovo je osnovni zaštitni mehanizam koji mora ugraditi svaka Web aplikacija kako bi se osigurao pristup osjetljivim informacijama. Obično postoji više kategorija korisnika koji pristupaju i koriste Web aplikaciju. Tako postoje neautentificirani (anonimni) korisnici, autentificirani korisnici i korisnici s administratorskim pravima (administratori). Zbog toga što postoji više kategorija korisnika mora postojati i mehanizam identifikacije korisnika. Isto tako, svaki korisnik nema ista prava. Neki korisnici imaju veća prava, neki manja. Svaki korisnik nije autoriziran da pristupi svakom dijelu aplikacije, npr. administratorskom dijelu aplikacije pristup bi trebao imati samo administrator. Zbog toga postoje mehanizmi koji osiguravaju kontrolu pristupa različitim dijelovima Web aplikacije.

Kontrola korisničkog pristupa u Web aplikacijama ostvaruje se ugrađivanjem tri osnovna zaštitna mehanizma, a to su:

• autentifikacija,
• kontrola sjednice i
• kontrola pristupa. [10]

3.1.1.1 Autentifikacija

Autentifikacija korisnika koristi se kako bi se utvrdilo da je korisnik stvarno onaj za kojeg se predstavlja da je. Ukoliko nema autentifikacije korisnika svi se korisnici moraju tretirati kao anonimni korisnici i daje im se najmanja moguća razina povjerenja.

Autentifikacija se standardno provodi pomoću korisničkog imena i lozinke. Korisnik kako bi se prijavio na Web aplikaciju koristi svoje korisničko ime i lozinku koju samo on zna. Nakon što korisnik unese svoje podatke, Web aplikacija provjerava vjerodostojnost tih podataka i dopušta da se korisnik prijavi na sustav ili odbacuje prijavu. U nekim naprednijim Web aplikacijama u kojima je potrebna veća razina sigurnosti provode se složeniji postupci autentifikacije korisnika. Složenija autentifikacija od korisnika obično zahtjeva još informacija, osim korisničkog imena i lozinke, i autentifikacija se provodi u više koraka. Ukoliko Web aplikacija zahtjeva veliku razinu sigurnosti, za autentifikaciju se koristi autentifikacija putem pametnih kartica, klijentskih certifikata, uređaja kao što su tokeni (engl. challenge-response token) i dr.

Osim procesa prijave korisnika u Web aplikacijama obično se ostvaruje i niz pomoćnih mogućnosti kao što su registracija korisnika, aktivacija i deaktivacija korisničkog računa, obnova lozinke i sl.

Ukoliko je ranjiv bilo koji dio autentifikacije, zbog grešaka u programskom ostvarenju i logičkih grešaka, ranjiva je i cijela Web aplikacija. Napadač iskorištavanjem nekih od tih ranjivosti može kompromitirati cijelu Web aplikaciju. Napadač može u potpunosti zaobići autentifikaciju pogađanjem korisničkog imena i lozinke ili iskorištavanjem logičkih grešaka u programskom ostvarenju autentifikacije.

3.1.1.2 Kontrola sjednice

Nakon uspješne autentifikacije korisnik pristupa različitim dijelovima i funkcijama Web aplikacije, šaljući niz zahtjeva pomoću svog Web preglednika. U isto vrijeme Web aplikacija dobiva veliki broj drugih zahtjeva od drugih korisnika, od kojih su neki autentificirani, a neki su anonimni. Kako bi se osigurala kontrola korisničkog pristupa Web aplikacije moraju ugraditi zaštitni mehanizam koji će identificirati i obraditi pristigle korisničke zahtjeve od različitih korisnika. U Web aplikacijama to se rješava tako da se za svakog korisnika napravi sjednica i svakom korisniku se dodjeli jedinstveni sjednički identifikator (engl. session ID). Razlog zbog kojeg je potrebno ugraditi dodati zaštitni mehanizam je to što Web aplikacije kao komunikacijski protokol koriste HTTP. HTTP je protokol bez stanja (engl. stateless protocol), svaki zahtjev promatra se i obrađuje zasebno, neovisno o prethodnom zahtjevu i na nikakav način ne raspoznaje pojedinog korisnika.

Sjednički identifikator je jedinstveni znakovni niz pomoću kojeg Web aplikacija razlikuje pojedinog korisnika. Sjedničke identifikatore izdaje Web aplikacija, te se oni čuvaju i na Web poslužitelju i kod korisnika. Nakon što Web aplikacija izda sjednički identifikator korisniku, korisnik ga pri svakom HTTP zahtjevu šalje Web aplikaciji kako bi ga Web aplikacija mogla identificirati. HTTP kolačići (engl. HTTP cookies) su standardan način prijenosa i spremanja sjedničkih identifikatora, a još se koriste i sjednički identifikatori pohranjeni u skrivena polja (engl. hidden fields) ili unutar samog URL-a. Svaki sjednički identifikator ima svoj životni vijek trajanja nakon kojega sjednički identifikator prestaje biti valjan. Nakon isteka tog vremena od korisnika se traži da ponovno prođe proces autentifikacije ukoliko i dalje želi koristiti usluge Web aplikacije.

Sigurnost kontrole sjednice u potpunosti ovisi o sigurnosti sjedničkih identifikatora. Napadi na kontrolu sjednice usmjereni su prema kompromitiranju korisničkog sjedničkog identifikatora. Ukoliko napadač dođe u posjed ispravnog sjedničkog identifikatora može zaobići autentifikaciju i koristiti Web aplikaciju sa svim pravima koje ima korisnik čiji je sjednički identifikator kompromitiran. Obično ranjivosti proizlaze iz lošeg programskog ostvarenja generatora sjedničkih identifikatora i manipulacije sa sjedničkim identifikatorima.

3.1.1.3 Kontrola pristupa

Nakon uspješne autentifikacije i nakon što korisnik dobije svoj sjednički identifikator korisnik može koristiti usluge Web aplikacije, pristupati različitom sadržaju i funkcijama. Iako je korisnik uspješno autentificiran to ne znači da je autoriziran da pristupa svim dijelovima Web aplikacije i da koristi sve raspoložive usluge. Zbog toga je potrebno ugraditi zaštitni mehanizam kontrole pristupa kako bi se osiguralo da korisnik pristupa samo onim dijelovima Web aplikacije za koje je i autoriziran.

Mehanizam kontrole pristupa mora moći raspoznavati o kojem se tipu korisnika radi i čemu sve pojedini tip korisnika smije i ne smije pristupiti. Svaki zahtjev koji korisnik uputi Web aplikaciji mora proći kroz ovu provjeru, kako bi se utvrdilo ima li korisnik pravo pristupa zatraženom dijelu Web aplikacije ili nema.

Kontrola pristupa može se podijeliti u dvije osnovne kategorije, a to su:

• horizontalna kontrola pristupa i
• vertikalna kontrola pristupa.

Mehanizam horizontalne kontrole pristupa omogućava korisnicima s istim korisničkim pravima da pristupaju određenom podskupu sadržaja i funkcija Web aplikacije koji su istog tipa. Horizontalnom kontrolom pristupa kontrolira se da korisnici koji imaju ista prava mogu pristupiti samo svom sadržaju, a ne i sadržaju drugih korisnika s istim pravima. Primjer horizontalne kontrole pristupa je kada u Web aplikacijama za elektroničku poštu korisnici mogu pristupati samo svom poštanskom sandučiću, a ne mogu pristupiti sandučićima drugih korisnika koji imaju ista korisnička prava kao i oni.

Mehanizam vertikalne kontrole pristupa omogućava različitim vrstama korisnika da pristupaju različitim vrstama sadržaja i funkcijama Web aplikacije. Vertikalna kontrola pristupa omogućava da se napravi razlika između korisnika s administratorskim pravima i običnih korisnika. U nekim slučajevima koristi se kako bi se napravila fina podjela korisničkih uloga, dodjeljivanjem svakom korisniku jednu ili više uloga koje omogućavaju pristup određenom sadržaju i funkcijama Web aplikacije.

Zbog relativne kompleksnosti izvedbe ovakvog mehanizma, logičkih grešaka i grešaka u programskom ostvarenju, ovaj mehanizam je čest izvor ranjivosti. Ranjivosti u ovom dijelu omogućavaju napadaču pristup podacima i funkcijama Web aplikacije kojima inače ne bi smio pristupiti. Razlog nastanka ranjivosti je većinom radi loše pretpostavke programera o tome kako će korisnici koristiti aplikaciju, te izostavljanjem ugradnje kontrole pristupa za neke dijelove Web aplikacije.

3.1.2 Kontrola korisničkog unosa

Jedan od osnovnih sigurnosnih problema s kojima su suočene Web aplikacije je to da se korisnik nalazi izvan aplikacijske kontrole. Zlonamjeran korisnik aplikaciji može poslati proizvoljan zahtjev posebno modificiran kako bi iskoristio pronađenu ranjivost Web aplikacije kako bi izveo željenu radnju. Prosljeđivanjem posebno modificiranog korisničkog unosa (korisničkih ulaznih podataka), umjesto normalnog korisničkog unosa, može se izazvati da se Web aplikacija ponaša drugačije od zamišljenog. Zbog toga je za sigurnost Web aplikacije jako bitno na koji način rukuje s korisničkim unosom. Sav korisnički unos trebao bi se smatrati nesigurnim i trebao bi proći kroz fazu ispitivanja valjanosti prije korištenja unutar Web aplikacije. Ranjivosti vezane uz korisnički unos mogu se pojaviti bilo gdje unutar Web aplikacije gdje postoji korisnički unos. Postoje dvije vrste korisničkog unosa. Prva vrsta korisničkog unosa je onaj unos kod kojeg se od korisnika direktno traži da unese neke podatke, kao što su npr. korisničko ime i lozinka, popunjavanje raznih formi i sl. Pod drugu vrstu korisničkog unosa spadaju podaci koje je Web aplikacija poslala korisniku i očekuje od korisnika da će joj on te podatke u sljedećem zahtjevu vratiti nazad. Pod te podatke spadaju sjednički identifikatori, vrijednosti spremljene u skrivenim poljima, razni identifikatori potrebni za funkcioniranje aplikacije i sl. Ove podatke korisnik ne postavlja direktno, ali ukoliko želi može ih izmijeniti i tako izmijenjene poslati Web aplikaciji.

Postoji više pristupa koji se koriste kako bi se kontrolirao korisnički unos i time spriječili napadi na Web aplikacije. Različiti pristupi se upotrebljavaju za različite situacije i vrste korisničkog unosa, a ponekada se koristi i kombinacija nekoliko različitih pristupa. Obično se provodi filtriranje korisničkog unosa, pa se mehanizmi za kontrolu korisničkog unosa obično nazivaju filteri.

Neki od pristupa rješavanja ovih problema su:

• odbacivanje poznatih loših unosa (engl. Reject Known Bad),
• prihvaćanje poznatih dobrih unosa (engl. Accept Known Good) i
• preoblikovanje korisničkog unosa (engl. Sanitization). [10]

3.1.2.1 Odbacivanje poznatih loših unosa

U ovom pristupu koristi se lista korisničkih unosa za koje se sigurno zna da su loši, tj. da mogu naštetiti Web aplikaciji. Lista sadrži nizove znakova za koje se zna da su loši, isto tako sadrži i uzorke nizova znakova koji se koriste u poznatim napadima. Mehanizam provjere radi na taj način da sve korisničke unose koji se poklapaju s nekim od nizova u listi odbacuje, a sve ostale korisničke unose prihvaća.

Ovakav pristup kontrole korisničkog unosa je najmanje efikasan iz dva osnovna razloga. Prvi razlog je to što se jedna ranjivost može iskoristiti na više različitih načina, korisničkih unosa, koji mogu biti kodirani ili prikazani na mnogo različitih načina. Zbog toga je moguće da filter koji koristi ovaj pristup propusti neki niz znakova koji se mogu iskoristiti za napad na Web aplikaciju. Drugi razlog je brzo zastarijevanje liste poznatih loših unosa. Tehnike iskorištavanja ranjivosti u Web aplikacijama konstantno se razvijaju i zbog toga je moguće da neka nova tehnika iskorištavanja postojećih ranjivosti neće biti zaustavljena sa zastarjelom listom poznatih loših unosa.

3.1.2.2 Prihvaćanje poznatih dobrih unosa

U ovom pristupu koristi se lista korisničkih unosa za koje se sigurno zna da su bezopasni za Web aplikaciju. Lista sadrži prihvatljive nizove znakova, prihvatljive uzorke znakova ili se koristi skup kriterija koji se podudaraju sa sigurnim unosom. Mehanizam provjere radi tako da propušta sve korisničke unose koji se podudaraju s listom, a sve ostale unose odbacuje.

U slučajevima kada je moguće koristiti ovakvu listu unosa, ovo je najefikasniji način sprečavanja prolaska zlonamjernih korisničkih unosa. Ukoliko se koristi ovaj pristup zlonamjerni korisnik neće moći koristiti posebno modificirane korisničke unose kako bi izazvao neželjeno ponašanje Web aplikacije. Ali u nekim slučajevima nije moguće koristiti listu poznatih dobrih unosa. Ponekada Web aplikacija mora prihvatiti i obraditi korisnički unos koji ne zadovoljava kriterije postavljene listom poznatih unosa. Jedan od primjera je ako korisnik u svom imenu ima jednostruki navodnik. Jednostruki navodnici se obično koriste za iskorištavanje propusta unutar Web aplikacija za napad na baze podataka. S druge strane Web aplikacija mora dopustiti registriranje korisnika s njegovim punim imenom. Zbog toga i ako je lista poznatih dobrih unosa dosta efikasna nije potpuno rješenje za kontrolu korisničkog unosa, jer se jednostavno u nekim slučajevima ne može koristiti.

3.1.2.3 Preoblikovanje korisničkog unosa

Ovaj pristup se koristi kada postoji potreba za prihvat korisničkog unosa za koji se sa sigurnošću ne može reći da je siguran. Umjesto odbacivanja ovakvih korisničkih unosa oni se preoblikuju tako da ne mogu imati nikakav negativan utjecaj na Web aplikaciju. Potencijalno opasni znakovi mogu se u potpunosti izbaciti iz korisničkog unosa (kao što su npr. jednostruki navodnici ili znakovi za otvaranje i zatvaranje HTML tag-ova), mogu se prikladno kodirati ili se na neki način mogu isključiti (izbjeći, deaktivirati) prije obrade unutar Web aplikacije.

Ovakav pristup kontrole korisničkog unosa je obično jako efikasan i u mnogim slučajevima može se koristiti kao generalno rješenje za rješavanje zlonamjernog korisničkog unosa.

3.1.3 Odgovor na napad na sigurnost Web aplikacije

Za svaku Web aplikaciju za koju je sigurnost od velikog interesa mora se pretpostaviti da će aplikacija kad-tad biti izložena napadu upornih i možda iskusnih napadača. Zbog toga ključni element sigurnosti Web aplikacije je to kako ona reagira na napad i koje mjere se poduzimaju ukoliko aplikacija bude izložena napadu. Mjere za obranu od napada obično uključuju defenzivne i ofenzivne mjere. Mjerama se obično pokušava frustrirati napadača što je više moguće kako bi on odustao od napada, omogućavaju vođenje prikladnih zabilješki i prikupljanje potrebnih dokaza o izvedenom napadu. Mjere za kontrolu napada obično obuhvaćaju sljedeće elemente:

• kontrola grešaka,
• vođenje kontrolnih zapisa,
• obavještavanje administratora i
• reakcija na napad. [10]

3.1.3.1 Kontrola grešaka

Neovisno o tome koliko se pažnje posvetilo kontroli korisničkog unosa neizbježno je da će tijekom rada Web aplikacije i obrade korisničkog unosa ponekada dolaziti do neočekivanih grešaka u radu aplikacije. Greške koje se mogu pojaviti tijekom normalnog korisničkog rada obično su sanirane i prikladno obrađene tijekom izrade Web aplikacije i faze ispitivanja. Neočekivane greške mogu se pojaviti tijekom napada na Web aplikaciju. Dosta je teško predvidjeti sve moguće načine na koje napadač može biti u interakciji s Web aplikacijom i zbog toga je za očekivati da se tijekom napada pojavi i neka neočekivana greška.

Jedan od ključnih zaštitnih mehanizama je i kontrola grešaka. Web aplikacija mora biti u mogućnosti da na prikladan način obradi neočekivane greške tako da se u potpunosti oporavi od njih ili da korisniku pošalje prikladnu poruku o grešci. Aplikacija niti u kojem slučaju ne bi smjela vraćati i korisniku prikazivati sistemski generirane greške. Sistemski generirane greške odaju previše povjerljivih informaciju o samoj Web aplikaciji. Ukoliko kontrola grešaka nije ostvarena na siguran način napadač to može iskoristiti u svoju korist kako bi prikupio osjetljive informacije i olakšao si napad na Web aplikaciju. Zbog toga je jako bitno da greške koje se prikazuju korisniku budu što jednostavnije bez osjetljivih informacija koje bi se mogle iskoristiti za kompromitiranje Web aplikacije.

3.1.3.2 Vođenje kontrolnih zapisa

Vođenje kontrolnih zapisa (engl. audit logs) jako je bitno za sigurnost Web aplikacije. Dobro vođeni kontrolni zapisi omogućavaju da se točno vidi što se sve dogodilo tijekom napada na Web aplikaciju, ukoliko je do njega došlo. Trebali bi dati uvid u sve što je napadač radio tijekom napada (iskorištene ranjivosti, neautorizirani pristup funkcijama i podacima, sve provedene akcije i sl.). Isto tako informacije iz kontrolnih zapisa trebale bi omogućiti ili olakšati otkrivanje stvarnog identiteta napadača, kako bi ga se moglo zakonski sankcionirati.

U kontrolne zapise obično se zapisuju sve informacije o dobivenim zahtjevima. Zapisuju se informacije kao što su točno vrijeme dolaska zahtjeva, IP adresa s koje je zahtjev došao, korisničke informacije (ukoliko je korisnik autentificiran), koji resurs Web aplikacije je bio zatražen i sl. Zbog toga što kontrolni zapisi sadrže jako osjetljive informacije (korisnička imena, lozinke, sjedničke identifikatore) potrebno je voditi računa i o njihovom pohranjivanju. Pristup kontrolnim zapisima mora biti ograničen i osiguran. Ukoliko se zahtjeva veća razina sigurnosti obično se spremaju na posebna računala kojima pristup jedino ima Web aplikacija.

Loša i nesigurna pohrana kontrolnih zapisa predstavlja veliki sigurnosni rizik. Ukoliko napadač dođe u posjed kontrolnih zapisa samo s pomoću informacija prikupljenih iz njih može kompromitirati cijelu Web aplikaciju. Zbog toga sigurno spremanje kontrolnih zapisa je od ključne važnosti za sigurnost Web aplikacija.

3.1.3.3 Obavještavanje administratora

Ponekada nije dovoljno voditi samo kontrolne zapise. Kontrolni zapisi se koriste nakon što je napad već izveden, a ponekad to nije dovoljno. U nekim situacijama potreban je trenutačan odgovor na napad kako bi se smanjile njegove posljedice. Ukoliko ih se pravodobno obavijesti, administratori mogu reagirati u realnom vremenu i spriječiti napad koji je u tijeku ili smanjiti njegovo posljedice. Administratori mogu blokirati IP adrese s kojih se provodi napad ili blokirati korisničke račune koji su kompromitirani ili ih napadač koristi za napad. U najgorem slučaju mogu ugasiti Web aplikaciju, onemogućiti joj pristup s Interneta, kako bi se provela istraga i poduzele potrebne mjere.

Kako bi se omogućilo pravodobno obavještavanje administratora potrebno je ostvariti mehanizam koji otkriva izvođenje napada na Web aplikaciju. Kako bi bio efikasan taj mehanizam mora biti pouzdan u otkrivanju napada kako administratore ne bi obavještavao o lažnim napadima. Obično se za tu svrhu koriste različiti IDS (engl. Intrusion Detection System) sustavi i vatrozidovi (engl. firewall).

3.1.3.4 Reakcija na napad

Uz mehanizam za obavještavanje administratora neke Web aplikacije, za koje je sigurnost od velikog značaja, imaju ugrađene mehanizme koji defenzivno reagiraju prema potencijalno malicioznim korisnicima.

Kako je svaka Web aplikacija drugačija, kako bi napadač otkrio neku od uobičajenih ranjivosti unutar Web aplikacije mora poslati veliki broj posebno modificiranih zahtjeva. Ukoliko je ostvaren dobar mehanizam za kontrolu korisničkog unosa, taj mehanizam će otkriti većinu zahtjeva koje šalje napadač i oni neće loše utjecati na Web aplikaciju. Mora se pretpostaviti da niti jedan filter koji kontrolira korisnički unos nije savršen i da postoji način da se zaobiđe. Iz tog razloga ako je napadač uporan potencijalno postoji mogućnost da će na kraju i otkriti neku ranjivost unutar Web aplikacije. Kako bi riješili ovaj problem neke Web aplikacije ugrađuju mehanizam koji u tom slučaju automatski reagira i izvodi niz mjera kako bi zaustavio napadača. Neke od mjera su: sve sporije posluživanje zahtjeva koje šalje napadač, prekidanje napadačeve sjednice kako bi se morao ponovno prijaviti na sustav nakon svakog zahtjeva, blokiranje IP adrese s koje dolaze zahtjevi i sl. Ove mjere neće zaustaviti najupornije napadače, ali će usporiti napadača s čime će administratori dobiti nešto više vremena za analizu napada i provođenje drastičnijih mjera, ako su potrebne.

3.1.4 Održavanje Web aplikacije

Svaka naprednija Web aplikacija zahtjeva i održavanje, administraciju. Za normalan rad Web aplikacije potrebno je održavati sve njezine dijelove i funkcije, kao što su: administracija korisnika, vođenje i pristup kontrolnim zapisima, konfiguriranje aplikacijskih funkcija, provođenje dijagnostičkih kontrola i dr.

U mnogim Web aplikacijama administratorske funkcije ugrađene su unutar same aplikacije. Obično se za pristup administratorskim funkcijama koristi Web sučelje, kao i za ostatak aplikacije. Administratorski dio obično je meta napada iz razloga što kompromitiranjem tog dijela kompromitirana je i cijela Web aplikacija, a u nekim slučajevima i Web poslužitelj na kojem se nalazi Web aplikacija. Zbog loše kontrole pristupa napadač može doći do pristupa administratorskom dijelu ili možda samo nekim njegovim funkcijama i na taj način ugroziti cijelu Web aplikaciju. Zbog toga je jako bitno dobro osigurati administratorski dio i sve njegove funkcije od neautoriziranog pristupa i pristup omogućiti samo administratorima Web aplikacije. [10]

3.2 Ranjivosti Web aplikacija i njihovo otkrivanje

Jedan od osnovnih sigurnosnih problema vezanih uz Web aplikacije, kao što je već rečeno, je to da se korisnik nalazi izvan aplikacijske kontrole. Korisnik je potpuno slobodan i Web aplikacija ne može kontrolirati što će joj korisnik poslati. Naravno, ovako stanje iskorištava napadač kako bi iskoristio ranjivosti Web aplikacije, te kako bi proveo željenu zlonamjernu radnju. Ranjivosti obično nastaju zbog lošeg programskog ostvarenja zaštitnih mehanizama i loše sigurnosne osviještenosti programera. Drugi razlog nastanka je ograničeno vrijeme tijekom izrade Web aplikacije. Kako su programeri ograničeni vremenom izrade Web aplikacije, malo vremena se odvaja za sigurnost Web aplikacije i provođenje penetracijskog ispitivanja sigurnosti. Ako se i provodi penetracijsko ispitivanje sigurnosti Web aplikacije, ono se obično provodi na kraju procesa izrade, te u jako ograničenom vremenskom razdoblju. Tako na brzinu obavljeno penetracijsko ispitivanje sigurnosti Web aplikacije može otkriti samo očite ranjivosti, a one teže za otkrivanje u većini slučajeva ostaju neotkrivene. Kako bi se smanjila pojava ranjivosti Web aplikacija, potrebno je voditi brigu o sigurnosti kroz sve faze izrade Web aplikacije. Prije puštanja Web aplikacije u rad potrebno je provesti opsežno penetracijsko ispitivanje sigurnosti Web aplikacije, kako bi se potencijalne ranjivosti pronašle i ispravile.

Postoji nekoliko organizacija koje se bave sigurnošću u računalom svijetu, pa i sa sigurnošću Web aplikacija. Neke od poznatijih organizacija su CERT (Computer Emergency Response Team), OWASP (Open Web Application Security Project), WASC (Web Application Security Consortium), SANS Institue i dr. Sve navedene organizacije bave se sa sigurnošću u računalnom svijetu, ali organizacije OWASP i WASC svoj su rad i djelovanje detaljno posvetili sigurnosti Web aplikacija. Cilj ovih organizacija je podizanje svijesti o sigurnosti Web aplikacija, pružanje podrške korisnicima i programerima, te sigurnosna edukacija.[12] [13] Na svojim Web stranicama objavljuju liste ranjivosti pronađenih u Web aplikacijama, daju savjete kako izbjeći i kako programirati Web aplikacije na siguran način i još puno toga.

OWASP periodički izdaje listu 10 najkritičnijih ranjivosti Web aplikacija. [11] Lista je izrađena prema statističkim podacima koji su prikupljeni provođenjem penetracijskog ispitivanja sigurnosti velikog broja Web aplikacija na Internetu. Trenutna lista se odnosi na 2007. godinu. Iako je lista stara sada već preko godinu dana i dalje je pouzdan pokazatelj najkritičnijih ranjivosti u Web aplikacijama. Najkritičnije ranjivosti Web aplikacija prema OWASP-u su:

• Izvršavanje napadačkog koda (engl. Cross Site Scripting – XSS)
• Ranjivosti na ubacivanje koda (engl. Injection Flaws)
• Izvođenje datoteka sa zlonamjernim sadržajem (engl Malicious File Execution)
• Nesigurna izravna referenca na objekt (engl. Insecure Direct Object Reference)
• Krivotvorenje zahtjeva (engl. Cross Site Request Forgery – CSRF)
• Curenje informacija i neispravno rukovanje pogreškama (engl. Information Leakage and Improper Error Handling)
• Kompromitirana autentifikacija i kontrola sjednice (engl. Broken Authentication and Session Management)
• Nesigurna kriptografska pohrana (engl. Insecure Cryptographic Storage)
• Nesigurna komunikacija (engl. Insecure Communications)
• Neuspješna zaštita pristupa URL-u (engl. Failure to Restrict URL Access)

U nastavku su opisane navedene najkritičnije i najčešće ranjivosti Web aplikacija. Neke od tih ranjivosti imaju i potkategorije, pa su i one detaljno opisane i objašnjene.

3.2.1 Izvršavanje napadačkog koda

Izvršavanje napadačkog koda (dalje u tekstu XSS) je najčešća ranjivost Web aplikacija. XSS je u biti napadačka tehnika s kojom se zlonamjeran kod ubacuje u kod HTML stranice koja se dinamički generira i prikazuje korisniku. Ranjivost se pojavljuje kada nije ostvarena dobra kontrola korisničkog unosa. Obično se pojavljuje u Web aplikacijama koje korisnički unos direktno koriste unutar HTML koda stranice koja se dinamički generira. Zbog nedostatka kontrole korisničkog unosa napadač može umjesto normalnog korisničkog unosa aplikaciji proslijediti napadački kod. Napadački kod se ubacuje u HTML kod prilikom dinamičkog generiranja stranice, te se tako omogućuje da se napadački kod izvrši unutar korisnikovog Web preglednika prilikom prikazivanja stranice korisniku. Za pisanje napadačkog koda napadači obično koriste JavaScript, ali moguće je koristiti i ostale skriptne jezike koji su podržani Web preglednikom (VBScript, ActiveX, Flash, i dr.). Iskorištavanje XSS ranjivosti napadaču omogućava izvođenje proizvoljnog napadačkog koda unutar korisnikovog Web preglednika što može rezultirati sa: krađom korisničkog sjedničkog identifikatora, provođenjem phishing napada, preusmjeravanje Web preglednika na proizvoljne lokacije, instaliranjem zlonamjernih programa i sl. Postojanjem XSS ranjivosti unutar Web aplikacije narušava se povjerljiv odnos između korisnika i Web aplikacije, jer su napadi korištenjem XSS-a direktno usmjereni protiv korisnika.

Postoje tri osnovna tipa XSS-a, a to su:

• reflektirani XSS (engl. reflected XSS),
• pohranjeni XSS (engl. stored XSS) i
• DOM ili lokalni XSS (engl. DOM-Based XSS).

Tipovi se razlikuju prema tome na koji način se napadački kod ubacuje, te kako se izvodi u korisnikovom Web pregledniku. U nastavku su detaljno opisana sva tri tipa XSS ranjivosti.

3.2.1.1 Reflektirani XSS

Reflektirani XSS je najjednostavniji i najčešći primjer XSS ranjivosti Web aplikacija, a isto tako je i najlakši za iskorištavanje. Javlja se bilo gdje unutar Web aplikacije gdje se vrijednost parametra iz URL-a ubacuje u kod HTML stranice koja se dinamički generira i prikazuje korisniku, a da se pritom vrijednost parametra ne provjerava. Jedan od primjera gdje se može pojaviti ranjivost je dinamičko generiranje opisa greške. Neka se za ispis opisa greške koristi URL prikazan na slici 3.1. Vrijednost koja se predaje parametru message se uzima i ubacuje se u HTML kod prilikom dinamičkog generiranja stranice.

Ako dio programskog koda, koji se u prethodnom primjeru koristi za ispis greške, izgleda kao na slici 3.2, aplikacija je ranjiva na reflektirani XSS. Ovaj dio programskog koda jednostavno uzima vrijednost parametra message i ubacuje ga u HTML kod, a to napadač može iskoristiti za ubacivanje proizvoljnog napadačkog koda.

Kako bi napadač iskoristio ovu ranjivost potrebno je da kao vrijednost parametra message postavi napadački kod, npr. skriptu napisanu u JavaScript-u. Skripta koja sigurno potvrđuje postojanje XSS ranjivosti je: <script>alert('XSS');</script>. Ako se umjesto opisa greške za vrijednost parametra message postavi navedena skripta i nakon što se tako modificirani URL pokrene unutar Web preglednika ubačena skripta se izvrši. U ovom slučaju skripta unutar Web preglednika otvara novi prozor i ispisuje XSS. (Slika 3.3)

Za napadača cilj iskorištavanja XSS ranjivosti je da dođe do povjerljivih korisničkih informacija, sjedničkih identifikatora ili da provede neku zlonamjernu radnju unutar korisnikovog Web preglednika. Na slici 3.4 prikazano je čitanje sjedničkog identifikatora iskorištavanjem ranjivosti Web aplikacije na reflektirani XSS. U ovom primjeru koristila se skripta koja pročitani sjednički identifikator prikazuje u novootvorenom prozoru unutar Web preglednika. Skripta koja je to omogućila je: <script>alert(document.cookie);</script>.

Kako bi napadač postojanje ranjivosti Web aplikacije na reflektirani XSS iskoristio u svoju korist, mora navesti korisnika da pokrene posebno modificirani URL koji u sebi sadrži napadački kod. Napadač nakon što pronađe ranjivost generira poveznicu na ranjivu Web aplikaciju koja u sebi sadrži napadački kod. Tako generirane poveznice napadač korisniku prosljeđuje slanjem elektronske pošte ili ih objavljuje na raznim forumima, blogovima ili socijalnim mrežama. Napadač na taj način može prevariti korisnika da pokrene poveznicu koja u sebi sadrži kod za krađu sjedničkog identifikatora. Na slici 3.5 prikazan je jedan takav napadački kod koji omogućuje krađu sjedničkog identifikatora. Svakom korisniku koji posjeti poveznicu koja sadrži takav napadački kod biti će ukraden sjednički identifikator i poslan napadaču. Napadač te sjedničke identifikatore može iskoristiti za pristup Web aplikaciji s istim pravima koje imaju i korisnici čije je sjedničke identifikatore ukrao.

Ranjivosti na reflektirani XSS su najjednostavnije i za otkrivanje. Za otkrivanje se iskorištava to da se u odgovoru na poslani zahtjev koji je sadržavao napadački kod uvijek vraća i taj poslani napadački kod. Automatizirani alati ovo iskorištavaju tako da za vrijednosti parametara postavljaju različite nizove znakova, tako generiran zahtjev šalju Web aplikaciji, te u dobivenom odgovoru gledaju pojavljuje li se poslani niz znakova. Ukoliko se poslani niz znakova pronađe u odgovoru, to je znak da postoji reflektirana XSS ranjivost, a u suprotnom da ne postoji. Obično se za tu svrhu kriste nizovi znakova koji su slučajno generirani ili se koriste stvarni napadački kodovi ili samo neki dijelovi napadačkih kodova. Ranjivost se može otkriti i analizom programskog koda otkrivanjem kritičnih programskih odsječaka, te ručno ispitivanjem ponašanja Web aplikacije. [12][14]

3.2.1.2 Pohranjeni XSS

Pohranjeni XSS, za razliku od reflektiranog XSS-a, napadački kod pohranjuje na Web poslužitelju. Obično se napadački kod pohranjuje u bazama podataka ili u datotekama na Web poslužitelju. Ova vrsta ranjivosti se javlja u Web aplikacijama u kojima su korisnici u međusobnoj interakciji, te korisnici mogu objavljivati svoj vlastiti sadržaj ili poruke kojima drugi korisnici mogu pristupati. Ako ne postoji kontrola korisničkog unosa za takve podatke, može doći do pojave ove vrste ranjivosti. Neke tipične Web aplikacije ranjive na ovu vrstu ranjivosti su: forumu, blogovi, socijalne mreže i sl.

Napadač može koristiti iste ili slične napadačke kodove kao i kod reflektiranog XSS-a kako bi došao do željenih podataka ili kako bi proveo željenu akciju. Napadač napadački kod obično ubacuje kroz različite mehanizme objavljivanja korisničkih poruka i sadržaja na Web aplikaciji. Na slici 3.6 prikazano je unošenje napadačkog koda kroz mehanizam dodavanja nove poruke na Web aplikaciji. Ubačeni kod se pohranjuje i izvršava se kada se pristupi stranici u koju je ubačen. U nekim slučajevima to može biti i stranica s koje je napadački kod i ubačen.

Napadač u ovom slučaju ne mora kreirati poveznice na ranjivu Web aplikaciju koje u sebi sadrže napadački kod i takve poveznice slati korisnicima kako bi ih oni pokrenuli. Dovoljno je da jednom napadački kod ubaci na Web aplikaciju i da čeka da korisnik pristupi stranici koja sadrži ubačeni napadački kod. Svaki puta kada korisnik pristupi stranici s napadačkim kodom on će se izvršiti. (Slika 3.7) Pohranjeni XSS se kao i reflektirani XSS koristi za krađu osjetljivih podataka, sjedničkih identifikatora, provođenje phishing napada, provođenje zlonamjernih radnji i sl. Pohranjeni XSS se u nekim slučajevima može koristiti i za izradu XSS crva, koji ranjivost iskorištavaju za širenje Web aplikacijom i računalnom mrežom. Postojanje ove vrste ranjivosti na sustavima s puno korisnika je iznimno rizično. U sustavima s puno korisnika napadač relativno brzo može doći do velikog broja korisničkih računa (sjedničkih identifikatora), te na taj način kompromitirati veliki broj korisničkih računa. Ako administrator sustava posjeti stranicu u kojoj se nalazi napadački kod, napadač krađom sjedničkog identifikatora može preuzeti kontrolu nad cijelom Web aplikacijom.

Otkrivanje ranjivosti na pohranjeni XSS je dosta zahtjevnije nego otkrivanje ranjivosti na reflektirani XSS. Automatizirani alati se mogu koristiti istim ili sličnim metodama kao za otkrivanje reflektiranog XSS-a, ali moraju se provoditi dodatne provjere. Kako se napadački kod ne mora vratiti odmah u odgovoru na poslani zahtjev, alati moraju provjeravati i ostale stranice na Web aplikaciji u potrazi za ubačenim napadačkim kodom, te voditi računa o tome na kojoj je stranici ubačen napadački kod, a na kojoj se pojavio. U nekim slučajevima automatizirani alati ne mogu otkriti postoji li ranjivost na pohranjeni XSS. Napadački kod se ponekada ubacuje na stranice kojima se ne može pristupiti (npr. administratorske stranice), te zbog toga u nekim slučajevima nije moguće koristiti automatizirane alate za pronalazak ranjivosti na pohranjeni XSS. Ranjivost se, kao i kod reflektiranog XSS-a, može otkriti analizom programskog koda i pronalaskom kritičnih programskih odsječaka, te ručno ispitivanjem ponašanja Web aplikacije. [12][14]

3.2.1.3 DOM ili lokalni XSS

Reflektirani i pohranjeni XSS donekle imaju isto ponašanje, napadački kod se ubacuje u Web aplikaciju, te se izvršava nakon što se zatraži stranica koja sadržava ubačeni napadački kod. DOM XSS se ne ponaša na taj način. DOM XSS ne koristi metodu ubacivanja napadačkog koda u Web aplikaciju, nego koristi ubacivanje na klijentskoj strani, odnosno iskorištavaju se propusti vezani uz izvršavanje klijentskih skripti napisanih u JavaScript-u u Web pregledniku.

Neke Web aplikacije koriste korisničke skripte napisane u JavaScript-u za obavljanje raznih funkcija, npr. ispis opisa grešaka, ispis pozdravnih poruka i sl. Skripte ponekada koriste DOM (Document Object Model) model kako bi pristupale različitim podacima unutar URL-a ili HTTP zaglavlja. Dobiveni podaci se obrađuju, te se ubacuju u HTML kod prilikom dinamičkog generiranja stranice. Ako Web aplikacija koristi takve korisničke skripte, postoji mogućnost da je ranjiva na DOM XSS.

U primjeru na slici 3.8 prikazana je jednostavna klijentska skripta koja se koristi za prikazivanje grešaka u radu Web aplikacije. Tekst greške je vrijednost URL parametra message. Kako se nigdje ne provjerava vrijednost parametra message napadač može, u ovom slučaju, ubaciti proizvoljan napadački kod i provesti proizvoljnu akciju.

Kako bi se pokazalo da postoji ranjivost na DOM XSS, parametru message predan je napadački kod, umjesto poruke o grešci. Na slici 3.9 je prikazano izvršavanje napadačkog koda iskorištavanjem XSS DOM ranjivosti. Napadački kod u ovom primjeru je bio: <script>alert('DOM XSS');</script>. Sve što ovaj napadački kod radi je da u novootvorenom prozoru ispisuje poruku DOM XSS.

Proces iskorištavanja ove ranjivosti za napadača je sličan procesu iskorištavanja ranjivosti na reflektirani XSS. Napadač mora generirati poveznicu koja u sebi sadrži napadački kod na ranjivu Web aplikaciju. Nakon toga mora navesti korisnika da generiranu poveznicu pokrene u svom Web pregledniku, kako bi se napadački kod izvršio.

Automatizirani alati često su neuspješni u otkrivanju ranjivosti na DOM XSS. Jedini siguran način otkrivanja ranjivosti je analiza programskog koda kako bi se utvrdilo na koji način se koriste kritične funkcije i varijable. Ako se u programskom kodu nađe kombinacija kritičnih funkcija i varijabli, može se pretpostaviti da može doći do pojavljivanja ranjivosti na DOM XSS. Neke od kritičnih varijabli i funkcija koje bi trebalo provjeriti na koji način se koriste unutar korisničkih skripti su: document.write, document.writeln, document.open, document.URLUnencoded, window.open, document.URL, document.location, document.referrer i dr. [10][11]

3.2.2 Ranjivosti na ubacivanje koda

Ranjivost na ubacivanje koda jedna je od najčešćih ranjivosti Web aplikacija. Ranjivost Web aplikacija na ubacivanje koda događa se kada se korisnički podaci koriste za kreiranje naredbi ili izradu upita u bazu podataka, a da se pri tome ti korisnički podaci ne provjeravaju sadrže li zlonamjerne znakove koji se mogu iskoristiti u zlonamjerne svrhe. Ako je Web aplikacija ranjiva na ubacivanje koda, napadač to može iskoristiti kako bi proveo željenu akciju ili izveo željenu naredbu. Postojanje ove ranjivosti napadaču obično omogućava čitanje, mijenjanje, brisanje proizvoljnih podataka koji se nalaze na Web aplikaciji, te u nekim slučajevima i dodavanje svojih vlastitih podataka. U najgorim slučajevima, napadač iskorištavanjem ove ranjivosti može kompromitirati cijelu Web aplikaciju, a i Web poslužitelj.

Postoji relativno veliki broj različitih vrsta ranjivosti Web aplikacija na ubacivanje koda, a neke od poznatijih ranjivosti su:

• SQL ubacivanje,
• LDAP ubacivanje,
• XPath ubacivanje i
• ubacivanje naredbi operacijskog sustava.

U nastavku su opisane sve navedene ranjivosti Web aplikacija na ubacivanje koda.

3.2.2.1 SQL ubacivanje

Danas gotovo svaka Web aplikacija koristi bazu podataka za spremanje aplikacijskih podataka potrebnih za rad aplikacije, a isto tako i za spremanje korisničkih podataka. Za rad s podacima koji se nalaze u bazama podataka obično se koristi strukturirani jezik za upite, SQL (Structured Query Language). SQL pomoću upita omogućuje rad s podacima koji se nalaze u bazi podataka. Pomoću SQL-a moguće je dodavati nove podatke, čitati, mijenjati i brisati već postojeće podatke. Za kreiranje SQL upita, za pristup podacima u bazi podataka, ponekada se koriste korisnički podaci. Ako ne postoji provjera korisničkog unosa, može doći do pojave ranjivosti na SQL ubacivanje. Napadač ovu ranjivost može iskoristiti tako da promijeni ispravan SQL upit u svoju korist i tako provede neku zlonamjernu radnju. Zbog velike raširenosti korištenja baza podataka u radu s Web aplikacijama, ranjivost na SQL ubacivanje je najčešća ranjivost Web aplikacija ranjivih na ubacivanje koda. Postoji velik broj vrsta baza podataka koje se koriste u radu s Web aplikacijama, a neke od najpoznatijih su: Oracle, MS-SQL i MySQL. [10]

Iskorištavanjem ranjivosti na SQL ubacivanje napadač može napraviti dosta štete na Web aplikaciji. Cilj izvođenja napada SQL ubacivanjem je obično krađa povjerljivih podataka iz baze podataka ili kompromitiranje baze podatak brisanjem ili mijenjanjem sadržaja. U nekim slučajevima mijenjanjem sadržaja i značenja SQL upita napadač može u potpunosti zaobići autentifikaciju i tako dobiti pristup zaštićenim dijelovima Web aplikacije. U primjeru na slici 3.10 prikazan je dio programskog koda koji se koristi za autentifikaciju korisnika, a koji je ranjiv na SQL ubacivanje.

Kako se parametri username i password dodatno ne provjeravaju i izravno se koriste u kreiranju SQL upita, napadač ovo može iskoristiti u svoju korist. Kako bi napadač ovu ranjivost iskoristio za prijavu na Web aplikaciju potrebno je da za vrijednosti parametara, odnosno korisničkog imena i lozinke, postavi sljedeći niz znakova: ' OR '1'='1. (Slika 3.11) Umetanjem ovog niza znakova napadač je preuredio SQL upit tako da je uvijek istinit i neovisno o tome što napadač ne zna ni korisničko ime ni lozinku prijava će uspjeti. Napadač će se u ovom slučaju prijaviti na Web aplikaciju kao prvi korisnik koji se nalazi u bazi podataka. Neke Web aplikacije kao prvog korisnika u bazi podataka imaju administratora Web aplikacije, u tom slučaju napadač je izvođenjem ovog SQL ubacivanja kompromitirao cijelu Web aplikaciju.

Postoje dvije osnovne vrste SQL ubacivanja, a to su: normalno SQL ubacivanje i slijepo SQL ubacivanje (engl. blind SQL injection). [12]

Normalno SQL ubacivanje oslanja se na greške koje se događaju kod neispravnog rada s bazama podataka, odnosno kada se bazi podataka pošalje neispravan SQL upit. Neke Web aplikacije ne saniraju takve greške, pa na stranicama s opisom greške odaju dosta informacija koje napadaču mogu biti korisne za provođenje napada ubacivanjem SQL upita. Iz tog razloga, napadači namjerno izazivaju greške ne bi li otkrili parametar ranjiv na SQL ubacivanje, te kako bi kroz dobivene greške prikupili podatke potrebne za izvođenje napada ubacivanjem SQL upita. Jedan o načina za namjerno izazivanje grešaka je ubacivanje specijalnih znakova unutar vrijednosti ili kao vrijednosti parametra ranjivog na SQL ubacivanje. Specijalni znakovi koji se koriste za ovu svrhu su: jednostruki navodnici, dvostruki navodnici i točka-zarez. Na slici 3.12 prikazana je poruka o grešci nastala radi ubacivanja jednostrukog navodnika u SQL upit. Poruka o grešci odaje zanimljive informacije kao što su: točan razlog nastanka greške, vrsta baze podataka, te broj linije u programskom kodu u kojoj se dogodila greška.

Još jedan način namjernog izazivanja grešaka je da se parametru koji je određenog tipa preda vrijednost drugog tipa. U primjeru na slici 3.13 cjelobrojnom parametru predan je znakovni niz, što je kod konvertiranja tog znakovnog niza u cjelobrojnu vrijednost rezultiralo greškom.

Sve prikupljene informacije iz poruka o greškama napadač koristi kako bi na što bolji način iskoristio pronađenu ranjivost na SQL ubacivanje, te kako bi proveo svoje zlonamjerne radnje.

U nekim slučajevima napadač za provođenje SQL ubacivanja koristi UNION operator. Napadač ovaj operator koristi kako bi spojio dva SQL upita, originalni SQL upit i svoj SQL upit. UNION operator omogućava da se rezultat tako spojenog SQL upita spoji s rezultatom originalnog SQL upita, te na taj način omogućava napadaču da čita povjerljive podatke iz baze podataka. Neka npr. originalni SQL upit izgleda kao na slici 3.14. Ako je parametar id ranjiv na SQL ubacivanje napadač to može iskoristiti kako bi proveo SQL ubacivanje koristeći UNION operator.

Na slici 3.15 prikazan je način iskorištavanja ranjivosti parametra id na SQL ubacivanje korištenjem UNION operatora.

Za uspješno izvođenje SQL ubacivanja koristeći UNION operator bitno je da i originalni SQL upit i napadačev nadovezani SQL upit imaju isti broj parametara, u suprotnom dolazi do pojavljivanja sintaksne greške. Primjer ispisa opisa jedne takve sintaksne greške prikazan je na slici 3.16. Ovakve opise sintaksnih grešaka napadač može iskoristiti za generiranje ispravnih SQL upita s ispravnim brojem parametara za provođenje SQL ubacivanja koristeći UNION operator.

Slijepo SQL ubacivanje se koristi kada Web aplikacija sanira greške nastale kod neispravnog rada s bazom podataka, te ne odaje nikakve informacije na stranicama s opisom greške. Iako Web aplikacija ne odaje nikakve informacije o greškama pri radu s bazom podataka, to ne znači da Web aplikacija nije ranjiva na SQL ubacivanje, jedino što je te ranjivosti teže pronaći. Slijepo SQL ubacivanje se koristi metodom ubacivanja istinitih i lažnih izjava u vrijednosti parametara, te se tako pokušava pronaći ranjivost Web aplikacije na slijepo SQL ubacivanje. Na slici 3.17 prikazan je dio koda koji je ranjiv na slijepo SQL ubacivanje.

Parametru id se dodaje istinita i lažna izjava. Dodavanje istinite izjave prikazano je na slici 3.18. Istinita izjava koja se dodaje je: AND '1'='1. Ako je Web aplikacija ranjiva na slijepo SQL ubacivanje, prikazati će se normalna zatražena stranica. Web aplikacija se u ovom slučaju ponaša normalno, kao da i nije ubačen nikakav dodatni kod, iz razloga što je ubačena izjava uvijek istinita (1=1).

Dodavanje lažne izjave prikazano je na slici 3.19. Lažna izjava koja se dodaje je: AND '1'='2. Zbog ubačene lažne izjave (1=2), sa SQL upitom se ne dohvaća niti jedan zapis iz baze podataka. Zbog toga se prikazuje stranica s porukom da traženi sadržaj ne postoji ili se ne prikazuje ništa, što je znak da je Web aplikacija ranjiva na slijepo SQL ubacivanje.

Automatizirani alati za otkrivanje ranjivosti na normalno SQL ubacivanje koriste se metodama s kojima namjerno izazivaju pojavljivanje grešaka. U vrijednosti parametara koji se ispituju postavljaju se specijalni znakovi koji će izazvati pojavljivanje greške. Analizom dobivenih stranica s greškom utvrđuje se je li Web aplikacija ranjiva na SQL ubacivanje. Za otkrivanje ranjivosti na slijepo SQL ubacivanje, automatizirani alati koriste se metodom dodavanja istinitih i lažnih izjava kao vrijednosti parametara. Analizom dobivenih odgovora, za istinite i lažne izjave, određuje se je li Web aplikacija ranjiva na slijepo SQL ubacivanje. Ako se ta dva odgovora razliku, to je znak da je Web aplikacija ranjiva na slijepo SQL ubacivanje. Analizom programskog koda može se utvrditi obavlja li se provjera korisničkih podataka koji se koriste u generiranju SQL upita. Ako se utvrdi da se korisnički podaci ne provjeravaju, može se zaključiti da je Web aplikacija ranjiva na SQL ubacivanje. [10][14]

3.2.2.2 LDAP ubacivanje

LDAP (Lightweight Directory Access Protocol) se koristi za pristup direktorijima preko računalne mreže. Direktoriji su hijerarhijska struktura koja se koristi za spremanje bilo kakvih podataka, a obično se koristi za spremanje osobnih podataka (korisnička imena, telefonski brojevi, adrese elektronske pošte i drugi osobni podaci). Jedan od primjera takvih direktorija je Active Directory koji se koristi na Windows domenama.

Neke Web aplikacije koriste LDAP kako bi pristupale korisničkim podacima. Za kreiranje LDAP upita obično se koriste korisnički ulazni podaci. Ako se LDAP upiti koriste za prikaz rezultata kod dinamičkog generiranja Web stranice i ako nema provjere korisničkih ulaznih podataka, Web aplikacija može biti ranjiva na LDAP ubacivanje. Primjer standardnog URL-a koji se može koristiti za generiranje LDAP upita prikazan je na slici 3.20.

Ako se parametar user direktno bez provjere vrijednosti koristi u konstruiranju LDAP upita, Web aplikacija je ranjiva na LDAP ubacivanje. Napadač može dodati proizvoljni LDAP upit, te tako pristupiti povjerljivim podacima. Jedan od načina iskorištavanja ranjivosti na LDAP ubacivanje prikazan je na slici 3.21. U ovom primjeru napadaču će se prikazati svi korisnici koji se nalaze na sustavu.

Automatizirani alati za otkrivanje ranjivosti na LDAP ubacivanje koriste se sličnim metodama kao i kod otkrivanja ranjivosti na SQL ubacivanje. Tijekom ispitivanja za vrijednosti parametara postavljaju se specijalni znakovi koji bi trebali izazvati grešku u radu. Analizom dobivenih grešaka utvrđuje se je li Web aplikacija ranjiva na LDAP ubacivanje. Ranjivost na LDAP ubacivanje može se otkriti i analizom programskog koda, te ručno ispitivanjem ponašanja Web aplikacije. [10][12]

3.2.2.3 XPath ubacivanje

XPath (XML Path Language) je programski jezik koji se koristi za rad s XML dokumentima, odnosno za čitanje podataka iz XML dokumenata. Za pristup podacima koriste se XPath upiti, s kojima se može pristupati određenim dijelovima i atributima XML dokumenta. U Web aplikacijama obično se za kreiranje XPath upita koriste korisnički ulazni podaci. Ako se korisnički ulazni podaci ne kontroliraju i direktno se koriste za kreiranje XPath upita, Web aplikacija može biti ranjiva na XPath ubacivanje. Xpath upiti su slični SQL upitima i mogu se koristiti za različite namjene. Na slici 3.22 prikazan je primjer jednog XPath upita koji se može koristi kod autentifikacije korisnika.

Ako se ne provjeravaju vrijednosti parametara LoginID i Passwd, napadač to može iskoristiti kako bi zaobišao autentifikaciju. Napadač u parametar Passwd može dodati sljedeći niz znakova: ' or '1'='1, te tako zaobići autentifikaciju. Dodavanjem tog niza znakova upit je uvijek istinit, jer uvijek vrijedi da je 1=1. XPath ubacivanje, kao što je pokazano u prethodnom primjeru, može se koristiti za zaobilaženje autentifikacije, ali isto tako može se koristiti za čitanje dijelova ili cijelog sadržaja XML dokumenata.

Otkrivanje ranjivosti na XPath ubacivanje slično je otkrivanju ranjivosti kod SQL ubacivanja i LDAP ubacivanja. Automatizirani alati za vrijednosti ispitivanih parametara postavljaju specijalne znakove kako bi izazvali pojavljivanje grešaka. Analizom dobivenih grešaka utvrđuje se je li Web aplikacija ranjiva na XPath ubacivanje. Ako Web aplikacija sanira poruke o greškama, u tom slučaju koriste se slične metode kao kod otkrivanja slijepog SQL ubacivanja. Ranjivost na XPath ubacivanje može se otkriti i analizom programskog koda, te ručno ispitivanjem ponašanja Web aplikacije. [10][12]

3.2.2.4 Ubacivanje naredbi operacijskog sustava

U nekim Web aplikacijama ulazni korisnički podaci koriste se kako bi se izvele naredbe operacijskog sustava. Ako ne postoji kontrola ulaznih korisničkih podataka, Web aplikacija može biti ranjiva na ubacivanje naredbi operacijskog sustava. Često se korisnički ulazni podaci koriste za dinamičko generiranje sadržaja HTML stranice ili za čitanje datoteka s Web poslužitelja. U primjeru na slici 3.23 prikazano je na koji način se datoteka uključuje u prikaz sadržaja HTML stranice. U ovom primjeru vrijednost parametra template predaje se funkciji za otvaranje datoteke, te se nakon toga pročitana datoteka prikazuje korisniku.

Ako se vrijednost parametra template ne provjerava, napadač to može iskoristiti kako bi ubacio proizvoljnu naredbu operacijskog sustava. U primjeru napadač kao vrijednost parametra template može umetnuti naredbu za listanje sadržaja trenutnog direktorija (/bin/ls), te koristeći znak za preusmjeravanje toka podataka (|) dobiti uvid u sadržaj direktorija. (Slika 3.24)

U nekim slučajevima napadač iskorištavanjem ove ranjivosti može na Web poslužitelju instalirani zlonamjerne programe, te teko preuzeti kontrolu nad poslužiteljem.

Automatizirani alati za otkrivanje ranjivosti na ubacivanje naredbi operacijskog sustava pokušavaju ubaciti naredbe za čitanje određenih datoteka s Web poslužitelja (npr. /bin/cat). Datoteke koje se pokušavaju pročitati su konfiguracijske datoteke koje sigurno postoje na poslužitelju (npr. /etc/passwd i C:\boot.ini). Nakon ubacivanja koda u dobivenom odgovoru se traže karakteristični nizovi znakova koje te datoteke sigurno sadrže. Ovisno o tome je li pronađen karakterističan niz znakova, određuje se je li Web aplikacija ranjiva na ubacivanje naredbi operacijskog sustava ili nije. Ranjivost na ubacivanje naredbi operacijskog sustava može se otkriti i analizom programskog koda, te ručno ispitivanjem ponašanja Web aplikacije. [11][12]

3.2.3 Izvođenje datoteka sa zlonamjernim sadržajem

Ponekada se u Web aplikacijama korisnički ulazni podaci koristi kako bi se izgradila referenca na datoteku na poslužitelju koja se izvršava. Ukoliko kontrola korisničkog unosa nije ostvarena kako treba može doći do pojave ove vrste ranjivosti. Napadač ovu ranjivost može iskoristiti u svoju korist tako da promjenom korisničkog unosa promjeni i referencu, te na taj način preusmjeri Web aplikaciju da izvede neku datoteku sa zlonamjernim sadržajem. Pokretanjem i izvršavanjem proizvoljnih datoteka napadač može izvoditi proizvoljne naredbe na poslužitelju, a u nekim slučajevima kompromitirati sustav i dobiti potpunu kontrolu nad cijelim sustavom. Šteta koju napadač može napraviti ovisi o korisničkim pravima s kojima je Web aplikacija pokrenuta na poslužitelju.

Iskorištavanjem ove ranjivosti napadač može Web aplikaciju preusmjeriti da izvede dva tipa datoteka, ovisno o tome gdje se datoteke nalaze. Ukoliko nema provjere promjene direktorija, napadač može pristupiti nekoj lokalnoj datoteci koja se nalazi u nekom drugom direktoriju na poslužitelju.(Slika 3.25)

Ako ne postoji provjera otvara li se datoteka s lokalnog ili udaljenog računala, napadač može pristupiti proizvoljnoj datoteci na udaljenom računalu.(Slika 3.26)

Razne Web aplikacije kao što su blogovi, socijalne mreže i forumi svojim korisnicima omogućavaju spremanje osobnih datoteka (npr. slike, filmovi i sl.) na poslužitelj. Ako Web aplikacija tijekom prijenosa tih datoteka ispravno ne obavlja i provjeru tipa datoteke, aplikacija postaje ranjiva na ovaj tip ranjivosti. U tom slučaju napadač jednostavno na poslužitelj legalnim putem može spremiti proizvoljnu zlonamjernu datoteku, obično se za tu svrhu koriste različite PHP shell skripte. (Slika 3.27)

Nakon uspješnog spremanja datoteke na poslužitelj, napadaču jedino još preostaje da jednostavno pristupi datoteci, te da provede željenu akciju. PHP shell skripta iz primjera na slici 3.27 omogućuje izvođenje proizvoljne naredbe operacijskog sustava. Naredba se zadaje preko vrijednosti parametra command. U primjeru na slici 3.28 izvedena je naredba cat /etc/passwd. Izvođenjem naredbe prikazuje se sadržaj konfiguracijske datoteke /etc/passwd koja se nalazi na Web poslužitelju.

Ova vrsta ranjivosti najzastupljenija je u Web aplikacijama napisanima u programskom jeziku PHP, ali ranjive su i druge platforme kao što su npr. Java i .NET.

Za otkrivanje ovog tipa ranjivosti automatizirani alati nisu efikasni. Automatizirani alati teško mogu procijeni koji parametar je ranjiv i na koji način se točno može iskoristiti ranjivost. Potrebno je ispitati svaki parametar posebno i provjeriti je li ranjiv na ovaj tip ranjivosti. Analizom programskog koda mogu se otkriti ranjivosti ovog tipa i točan način iskorištavanja ranjivosti. Ponekada pronalazak određenog parametra i pravog načina za iskorištavanje ranjivosti može biti dosta težak i dugotrajan posao. [10][11]

3.2.4 Nesigurna izravna referenca na objekt

U Web aplikacijama često se kao referenca za pristup različitim objektima aplikacije koristi URL, parametar forme ili sjednički identifikator. Ako kontrola pristupa objektima Web aplikacije nije ostvarena ili nije ostvarena na ispravan način, napadač može izmjenom reference doći do neautoriziranog pristupa drugim objektima Web aplikacije. Objekti Web aplikacije su obično različite datoteke, direktoriji, zapisi u bazi podataka, različiti dijelovi i funkcionalnosti Web aplikacije.

Ovu vrstu ranjivosti napadač može iskoristiti za:

• eskalaciju privilegija i
• pristup proizvoljnim datotekama i direktorijima.

3.2.4.1 Eskalacija privilegija

Web aplikacije reference obično koriste za pristupanje različitom korisničkom sadržaju Web aplikacije, odnosno korisničkim stranicama. Ako nije provedena dobra kontrola pristupa tom sadržaju, napadač manipulacijama s vrijednosti reference može doći do tog sadržaja. Do eskalacije privilegija (engl. privilege escalation) dolazi ako napadač dobije pristup sadržaju Web aplikacije za koji nema autorizaciju.

Postoje dva osnovna tipa eskalacije privilegija, a to su:

• horizontalna eskalacija privilegija (engl. horizontal privilege escalation) i
• vertikalna eskalacija privilegija (engl. vertical privilege escalation). (Slika 3.29)

Horizontalna eskalacija privilegija događa se kada napadač dođe do neautoriziranog pristupa sadržaju Web aplikacije koji pripada drugim korisnicima koji imaju ista ili slična korisnička prava kao i napadač. Neka se npr. za pristup određenoj korisničkoj stranici koristi parametar id unutar URL-a prikazanog na slici 3.30. Do horizontalne eskalacije privilegija dolazi ako napadač promjenom vrijednosti parametra id dođe do neautoriziranog pristupa nekoj drugoj korisničkoj stranici.

Vertikalna eskalacija privilegija događa se kada napadač dođe do neautoriziranog pristupa sadržaju Web aplikacije koji pripada korisnicima koji imaju veća korisnička prava (npr. administrator Web aplikacije) nego napadač. U nekim Web aplikacijama kako bi se razlikovali obični autentificirani korisnici od administratora koristi se skriveno polje unutar HTML forme. Ovisno o vrijednosti skrivenog polja autentificirani korisnik ima ili nema pravo pristupa administratorskom dijelu. U primjeru na slici 3.31 za razlikovanje korisnika koristi se skriveno polje site_admin. Za običnog korisnika vrijednost polja je F (false), a za administratora vrijednost polja je T (true). Do vertikalne eskalacije privilegija dolazi ako napadač promjenom vrijednosti polja na vrijednost T dobije neautorizirani pristup administratorskom dijelu Web aplikacije.

Ponekada se, kako bi se razlikovali običan korisnik i administrator, umjesto skrivenih polja koriste vrijednosti parametara unutar HTTP kolačića. U primjeru na slici 3.32 za razlikovanje korisnika koristi se parametar Admin. Za običnog korisnika parametar je postavljen na vrijednost false, a za administratora na true. Do vertikalne eskalacije privilegija dolazi ako napadač promjenom vrijednosti parametra na true i slanjem Web aplikaciji tako modificiranog HTTP zahtjeva dođe do neautoriziranog pristupa administratorskom dijelu Web aplikacije.

Kako ovaj tip ranjivosti spada i u logičke ranjivosti Web aplikacija, automatizirani alati nisu od prevelike koristi. Automatizirani alati ne mogu otkriti logičke ranjivosti unutar Web aplikacija, pa su zbog toga loši i u otkrivanju ranjivosti vezanih uz eskalaciju privilegija. Analizom programskog koda i ispitivanjem ponašanja Web aplikacije u različitim situacijama može se otkriti ova vrsta ranjivosti. [10][16]

3.2.4.2 Pristup proizvoljnim datotekama i direktorijima

Reference se ponekada u Web aplikacijama koriste za pristup proizvoljnim datotekama i direktorijima na poslužitelju, odnosno vrijednost parametra unutar URL-a predstavlja ime datoteke ili direktorija kojem se pristupa. Ako kontrola korisničkog unosa i pristupa nije ispravno ostvarena, napadač ovo može iskoristiti kako bi pristupio proizvoljnoj datoteci ili direktoriju na poslužitelju. Napadač iskorištavanjem ove ranjivosti obično može pristupiti osjetljivim informacijama na poslužitelju, a u najgorem slučaju može dobiti i potpunu kontrolu nad poslužiteljem.

Za iskorištavanje ove ranjivosti napadač obično koristi specijalni niz znakova pomoću kojih se proizvoljno kreće kroz direktorije dok ne dođe do direktorija u kojem se nalazi datoteka kojoj želi pristupiti (engl. path traversal). Niz znakova koje napadač koristi je "../" ili "..\", ovisno o vrsti Web poslužitelja i Web aplikacije. Taj niz znakova predstavlja prečac s kojim se napadač može pozicionirati u proizvoljan direktorij na poslužitelju i tako pristupiti datoteci koja se nalazi u tom direktoriju.

U primjeru na slici 3.33 prikazan je način korištenja prečaca kako bi se pristupilo određenoj datoteci na poslužitelju. U ovom primjeru pristupilo se datoteci passwd koja se nalazi u direktoriju /etc. Kako bi se pristupilo toj datoteci koristio se sljedeći specijalni niz znakova: ../../../../../../etc/passwd.

Zbog ugrađene kontrole korisničkog unosa u nekim slučajevima nije moguće koristiti standardne prečace kao što su "../" ili "..\", jer takvi nizovi znakova nisu prihvatljivi. Neka programska ostvarenja kontrole korisničkog unosa moguće je zavarati kodiranjem svih ili samo nekih znakova prečaca. Za tu svrhu koristite se različite vrste kodiranja znakova, kao što su npr. URL kodiranje, dvostruko URL kodiranje, Unicode kodiranje i UTF-8 Unicode kodiranje. Korištenjem npr. URL kodiranja specijalan niz znakova korišten u prethodnom primjeru imao bi sljedeći oblik: %2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd.

U nekim slučajevima na ime datoteke koje je predano kao vrijednost parametra unutar URL-a dodaje se ekstenzija za određenu vrstu datoteke. U primjeru na slici 3.34 na vrijednost parametra lang dodaje se ekstenzija .php. Korištenje standardnih prečaca za pristup datotekama u ovom slučaju ne bi bilo od koristi, jer bi se na kraj tog niza dodala i ekstenzija .php (npr. ../../../etc/passwd.php). U nekim slučajevima ovo je moguće zaobići dodavanjem NULL znaka na kraj niza, npr. ../../../etc/passwd%00 (gdje je %00 URL kodiran NULL znak). Dodavanjem NULL znaka omogućuje se da se prilikom čitanja datoteke zanemari dodatna ekstenzija datoteke, odnosno u znakovnom nizu sve iza NULL znaka se zanemaruje.

Dodavanjem NULL znaka na kraj imena datoteke u nekim slučajevima može se zaobići i loše programsko ostvarenje provjere ekstenzije datoteke unutar Web aplikacije i tako omogućiti pristup proizvoljnoj datoteci koristeći prečace.

Automatizirani alati mogu uspješno otkriti ranjivost nekog parametra na korištenje prečaca za pristup proizvoljnim datotekama. Ti alati obično koriste različite kombinacije prečaca kako bi pristupili konfiguracijskim datotekama na poslužitelju za koje se sigurno zna da postoje. Datoteke koje se obično koriste u ispitivanju su c:\boot.ini i /etc/passwd. Dobiveni odgovor, nakon što se zatraži željena datoteka, se analizira u potrazi za poznatim sadržajem. Navedene konfiguracijske datoteke uvijek sadrže neke karakteristične nizove znakova, pa se oni mogu iskoristiti za detekciju uspjeha pristupa tim datotekama. Ukoliko se poznati sadržaj nađe u odgovoru, ispitivani parametar je ranjiv na korištenje prečaca, a u suprotnom parametar nije ranjiv. Analizom programskog koda mogu se naći potencijalno ranjivi dijelovi koda na korištenje prečaca, te ispitivanjem ponašanja Web aplikacije može se utvrditi postoji li ili ne postoji ranjivost. [10][12]

3.2.5 Krivotvorenje zahtjeva

Provođenjem napada krivotvorenjem zahtjeva (dalje u tekstu CSRF) narušava se povjerenje između Web aplikacije i korisnikovog Web preglednika, za razliku od XSS napada koji narušava povjerljiv odnos između korisnika i Web aplikacije. Web aplikacija je ranjiva na CSRF ako je ranjiva na XSS, ali nepostojanje ranjivosti na XSS ne znači da Web aplikacija nije ranjiva na CSRF. CSRF nije nova vrsta ranjivosti, te je dosta raširena ranjivost Web aplikacija. Iskorištavanje CSRF ranjivosti je relativno jednostavno, a u nekim slučajevima posljedice iskorištavanja mogu biti poprilično ozbiljne. Cilj CSRF napada je slanje legitimnih HTTP zahtjeva Web aplikaciji na kojoj je korisnik autentificiran pomoću korisnikovog Web preglednika bez korisnikovog znanja, kako bi se provela neka zlonamjerna radnja.

Kada autentificirani korisnik pristupa sadržaju Web aplikacije Web preglednik automatski sa svakim HTTP zahtjevom šalje i HTTP kolačić, koji u sebi sadrži i sjednički identifikator. Većina Web aplikacija za raspoznavanje autentificiranih korisnika oslanja se samo na dobiveni HTTP kolačić poslan od korisnikovog Web preglednika. Ovakvo ponašanje Web aplikacije može se iskoristiti za provođenje CSRF napada. Napadač može napraviti zlonamjernu Web stranicu, koja u sebi sadrži zlonamjeran kod. Kada korisnik posjeti takvu Web stranicu zlonamjeran kod će od korisnikovog Web preglednika zatražiti da provede neke dodatne HTTP zahtjeve, bez korisnikovog znanja. Za ostvarivanje provođenja dodatnih HTTP zahtjeva obično se koristi HTML tag za prikaz slike (img). Kao izvor slike, vrijednost parametra src, navodi se željeni URL koji se želi posjetiti. Primjer napadačkog koda za provođenje dodatnog HTTP zahtjeva prikazan je na slici 3.35. Kada korisnikov Web preglednik učita napadački kod prikazan na slici 3.35, automatski će zatražiti URL koji je naveden u src parametru, kreiranjem novog HTTP zahtjeva. Ako je korisnik bio prijavljen na ranjivu Web aplikaciju, nakon izvršavanja tog dodatnog HTTP zahtjeva korisnik će biti odjavljen s Web aplikacije. Ovo je moguće izvesti zbog toga što Web preglednik automatski sa svakim zahtjevom upućenim Web aplikaciji na koju je korisnik prijavljen šalje i HTTP kolačić. Zbog toga je za uspješno provođenje CSRF napada potrebno da korisnik koji pristupi zlonamjernoj Web stranici bude prijavljen na Web aplikaciju ranjivu na CSRF.

U prethodnom primjeru prikazana je bezazlena radnja koja se izvodi iskorištavanjem ranjivosti Web aplikacije na CSRF. Iskorištavanjem CSRF ranjivosti mogu se provesti mnogo opasnije i složenije radnje, kao što je npr. krađa povjerljivih informacija, provođenje zlonamjernih akcija, krađa financijskih sredstava i sl.

Kako bi se Web aplikacije zaštitile od CSRF napada ugrađuju se neke dodatne zaštitne mjere. Jedna od zaštitnih mjera je umetanje slučajnih vrijednosti unutar svake Web stranice ili URL-a. Te slučajne vrijednosti se prilikom normalnog korištenja Web aplikacije šalju Web aplikaciji zajedno sa zahtjevom, te se na aplikacijskoj strani obavlja provjera odgovaraju li poslane vrijednosti stvarnim vrijednostima za trenutnog korisnika. Ako su vrijednosti iste zahtjev se prihvaća, inače se odbacuje. Prilikom CSRF napada Web preglednik ne šalje ove slučajne vrijednosti, pa se zbog toga svi krivotvoreni zahtjevi odbacuju i s time se onemogućuje izvođenje CSRF napada. Jedan od načina spremanja i prenošenja slučajnih vrijednosti prikazan je na slici 3.36. U ovom primjeru za spremanje slučajnih vrijednosti koristi se HTML forma, a vrijednosti se spremaju unutar skrivenih polja.

Ovakve zaštitne mjere, prikazane u prethodnom primjeru, mogu se zaobići ako je Web aplikacija ranjiva na XSS. Iskorištavanjem XSS ranjivosti Web aplikacije može se doći do informacija potrebnih za legitimno provođenje HTTP zahtjeva, pa se s time omogućuje i provođenje CSRF napada.

Automatizirani alati ne mogu otkriti ranjivost Web aplikacija na CSRF. Kako su dodatni HTTP zahtjevi koji se provode izvođenjem CSRF napada potpuno legitimni zahtjevi, automatizirani alati ne mogu raspoznati takve zahtjeve od normalnih korisničkih zahtjeva. Jedan dio ranjivosti Web aplikacije na CSRF može se otkriti otkrivanjem XSS ranjivosti Web aplikacije, jer gdje god postoji XSS ranjivost postoji i CSRF ranjivost. CSRF ranjivosti Web aplikacije mogu se pronaći i ispitivanjem na koji način Web aplikacija upravlja s autentificiranim korisnicima. Ako se Web aplikacija oslanja samo na dobiveni HTTP kolačić od Web preglednika, može se zaključiti da potencijalno postoji mogućnost da je aplikacija ranjiva na CSRF. [10][11]

3.2.6 Curenje informacija i neispravno rukovanje pogreškama

Curenje informacija i neispravno rukovanje pogreškama nije tip ranjivosti koji se direktno može iskoristiti kako bi se provela neka željena akcija ili kako bi se dobila kontrola nad Web aplikacijom. Ovaj tip ranjivosti, kao što i samo ime kaže, odaje informacije koje napadač može iskoristiti za iskorištavanje drugih tipova ranjivosti, te kako bi si olakšao provođenje napada na Web aplikaciju. Osjetljive informacije obično se otkrivaju kroz zaboravljene komentare unutar programskog koda ili unutar HTML stranica, zbog omogućene opcije listanja sadržaja direktorija i neispravnog rukovanja pogreškama. Čest je slučaj otkrivanja osjetljivih informacija i unutar samog HTTP zaglavlja u odgovoru Web poslužitelja. Unutar HTTP zaglavlja obično se odaju informacije kao što su: točna vrsta i verzija Web poslužitelja i točna vrsta programskog jezika u kojem je napisana Web aplikacija. Otkrivanje osjetljivih informacija kroz HTTP zaglavlja nije direktno vezano uz ranjivosti Web aplikacija, ali i te informacije mogu pomoći napadaču pri provođenju napada na Web aplikaciju.

Osjetljive informacije ponekada se mogu nalaziti u zaboravljenim komentarima unutar programskog koda ili koda HTML stranica. Takvi komentari mogu otkriti različite vrste osjetljivih informacija. Obično se u takvim komentarima nalaze opisi različitih dijelova programskog koda, opis načina funkcioniranja neke programske skripte, mrežna imena poslužitelja na mreži i slične opisne informacije. U nekim slučajevima unutar komentara u programskom kodu mogu se nalaziti i korisnička imena i lozinke koji su se koristili tijekom razvoja Web aplikacije. Ta korisnička imena i lozinke mogu biti važeći i nakon razvojne faze Web aplikacije, pa ih napadač jednostavno može iskoristiti za prijavu na Web aplikaciju. Sve ove informacije mogu napadaču biti od koristi, pa je zbog toga potrebno izbrisati sve suvišne i nepotrebne komentare iz programskog koda i koda HTML stranica.

Web poslužitelji obično imaju opciju listanja sadržaja direktorija ako se u direktoriju ne nalazi početna HTML stranica. Ranjivošću se smatra ako je listanje sadržaja nekog direktorija uključeno, a da se to nije htjelo. U tom slučaju listanjem sadržaja direktorija mogu se otkriti različite vrste datoteka koje možda ne bi trebale biti prikazane javnosti, pa ni napadaču. Listanjem sadržaja direktorija ponekada se mogu otkriti stare verzije HTML stranica i skripti, sigurnosne kopije datoteka, kontrolni zapisi i sl. Potrebno je napomenuti da napadač, neovisno o tome je li uključena opcija listanja sadržaja direktorija, može pristupiti tim datotekama ako nije provedena kontrola pristupa i ako im zna ili sazna ime.

Web aplikacija može odavati osjetljive informacije ako neispravno rukuje s pogreškama. Postoje dva tipa grešaka koje mogu nastati tijekom rada Web aplikacije, a to su: očekivane greške i neočekivane greške. Očekivane greške nastaju tijekom normalnog korištenja Web aplikacije. Jedna od očekivanih grešaka je npr. neuspješna prijava korisnika na Web aplikaciju. Stranica s greškom koja opisuje neuspjelu prijavu morala bi biti ista neovisno o tome je li upisana samo kriva korisnička lozinka ili su krivo upisani i korisničko ime i lozinka. Ponekada stranica s greškom otkriva da se uneseno korisničko ime nalazi u bazi, ali da je unesena lozinka neispravna. U tom slučaju nepotrebno se odaju informacije o postojećim korisničkim imenima u bazi podataka. Ovakvo ponašanje Web aplikacije napadač može iskoristiti kako bi skupio listu ispravnih korisničkih imena, koju kasnije može koristiti u napadu na Web aplikaciju. Neočekivane greške obično se javljaju kod napada na Web aplikaciju. Kako Web aplikacija tijekom napada dobiva velik broj neočekivanih HTTP zahtjeva, za očekivati je da će barem jedan izazvati neželjeno ponašanje Web aplikacije i grešku u radu. Ako ove greške nisu propisno sanirane mogu odavati veliki broj osjetljivih informacija koje napadaču mogu biti od velike koristi i olakšati mu iskorištavanje drugih ranjivosti. Ove greške obično odaju osjetljive informacije o unutrašnjoj strukturi Web aplikacije, pa se zbog toga najviše koriste kako bi se prikupile informacije potrebne za iskorištavanje ranjivosti na ubacivanje koda. U primjeru na slici 3.37 prikazana je nesanirana poruka o grešci u radu s bazom podataka prilikom korištenja Web aplikacije. U poruci o grešci je otkriveno ime baze, ime tablice, ime retka, te detaljan opis zašto je došlo do greške. Ovakva poruka o grešci se može iskoristiti kako bi se napravio ispravan SQL upit za iskorištavanje ranjivosti Web aplikacije na ubacivanje SQL upita.

Automatiziranim alatima je moguće otkriti curenje povjerljivih informacija. Automatizirani alati obično pokušavaju izazvati neočekivano ponašanje Web aplikacije, kako bi izazvali grešku, slanjem posebno modificiranih HTTP zahtjeva. Ranjivost se otkriva analizom dobivenog odgovora. U dobivenom odgovoru obično se traže ključne riječi koje se obično pojavljuju u većini opisa nastalih grešaka, kao što su npr. error, runtime error, exception, illegal, invalid, fail, stack, ODBC, SQL, SELECT i sl. Analizom koda može se utvrditi na koji se način obrađuju i očekivane i neočekivane greške, te se tako mogu otkriti dijelovi programskog koda koji mogu izazvati curenje povjerljivih informacija. [11][12]

3.2.7 Kompromitirana autentifikacija i kontrola sjednice

Autentifikacija i kontrola sjednice osnovni su i ključni sigurnosni mehanizmi koji osiguravaju sigurnost Web aplikacije i štite je od napadača. Ranjivosti ovih mehanizama obično rezultiraju potpunim kompromitiranjem Web aplikacije. Iskorištavanjem tih ranjivosti napadač u potpunosti može zaobići autentifikaciju i dobiti neautorizirani pristup sadržaju Web aplikacije ili može doći u posjed korisničkih imena i lozinki, sjedničkih identifikatora i drugih osjetljivih podataka.

3.2.7.1 Ranjivosti autentifikacije

Ranjivosti autentifikacije obično dovode do otkrivanja korisničkih imena i lozinki ili do potpunog zaobilaska procesa prijave korisnika i neautoriziranog pristupa podacima i funkcionalnostima Web aplikacije.

Jedna od ranjivosti autentifikacije je korištenje slabih korisničkih lozinki. Ukoliko Web aplikacija dopušta korištenje slabih korisničkih lozinki, takve lozinke su laka meta za napadače. Slabe korisničke lozinke su npr. kratke lozinke ili prazne lozinke (engl. blank), lozinke identične korisničkom imenu, lozinke koje se sastoje od uobičajenih riječi ili imena koje se mogu naći u rječniku i sl. Jedna od napadačkih metoda otkrivanja korisničkih imena i lozinki je metoda pretraživanja grubom silom (engl. brute force). To je automatizirani proces koji se koristi metodom pogađanja i promašaja kako bi pronašao ispravno korisničko ime i lozinku. Ova metoda koristi se rječnikom podataka (rječnik podataka sadrži standardna korisnička imena i lozinke) kako bi se proizvelo na tisuće neispravnih upita u potrazi za ispravnim korisničkim imenom i lozinkom. Postoje dvije osnovne vrste pretraživanja grubom silom, normalno pretraživanje grubom silom i reverzno pretraživanje grubom silom. Normalno pretraživanje grubom silom koristi jedno korisničko ime i veliki skup korisničkih lozinki, a reverzno pretraživanje grubom silom koristi jednu lozinku za velik skup korisničkih imena. Reverzno pretraživanje grubom silom efikasno je u sustavima koji imaju jako veliki broj korisnika, u tim sustavima znatno se povećava vjerojatnost da postoji više korisnika s istom lozinkom. Pretraživanje grubom silom je jako popularna i efikasna metoda, ali vrijeme trajanja pretraživanja može biti veliko. Vrijeme pretraživanja može se kretati od nekoliko minuta, sati, dana, tjedana, pa do nekoliko godina.

Još jedna ranjivost vezana uz autentifikaciju je nepotrebno odavanje informacija kod neuspjele autentifikacije. Ako Web aplikacija ne provodi dobru kontrolu prikaza grešaka korisniku kod neuspjele autentifikacije, može nepotrebno napadaču odavati korisne informacije. (Slika 3.38)

Iz primjera se vidi da Web aplikacija u slučaju neuspjele prijave odaje informaciju da se uneseni korisnik nalazi u bazi, ali da unesena lozinka nije ispravna. Ovakve greške dosta olakšavaju posao alatima koji koriste pretraživanje grubom silom. Korištenjem ovih poruka alati mogu prikupiti listu ispravnih korisničkih imena, te tako skratiti vrijeme otkrivanja ispravnog para, korisničkog imena i lozinke. Kako bi se spriječilo odavanje nepotrebnih informacija potrebno je da poruka o neuspjeloj prijavi uvijek bude ista, neovisno o tome je li uneseno ispravno korisničko ime ili ne.

Ako Web aplikacija ima proces prijave korisnika, mora omogućiti i proces obnove korisničke lozinke ukoliko ju korisnik zaboravi. Proces obnove lozinke obično se obavlja tako da korisnik mora odgovoriti na tajno pitanje (engl. secret question) kako bi pristupio procesu obnove lozinke. Tajno pitanje i odgovor na tajno pitanje korisnik obično odabire tijekom registriranja na Web aplikaciju i samo korisnik zna te informacije. Ukoliko je ovaj sustav ranjiv na napad pretraživanja grubom silom, napadač može doći do tih informacija, te pomoću tih informacija doći do korisničkih lozinki.

Ako se nekom sadržaju Web aplikacije koji bi trebao biti zaštićen može pristupiti bez prethodne autentifikacije, to se isto smatra ranjivošću autentifikacije. [10][12]

3.2.7.2 Ranjivosti kontrole sjednice

Ranjivosti unutar mehanizma kontrole sjednice obično omogućavaju napadaču da dođe do korisničkih sjedničkih identifikatora. Napadač u tom slučaju pribavljene sjedničke identifikatore iskorištava kako bi pristupio sadržaju Web aplikacije s pravima korisnika čiji su sjednički identifikatori kompromitirani, te na taj način krade identitet korisnicima.

Jedna od ranjivosti kontrole sjednice je korištenje loših i slabih algoritama za generiranje sjedničkih identifikatora. Ponekada se za generiranje sjedničkih identifikatora u Web aplikacijama koriste algoritmi koji na predvidiv način generiraju sjedničke identifikatore. Ako napadač shvati na koji način se generiraju sjednički identifikatori, on to može iskoristiti kako bi sam generirao veliki broj ispravnih sjedničkih identifikatora. Dobivene sjedničke identifikatore napadač može iskoristiti za kompromitiranje svih korisničkih računa do čijih je sjedničkih identifikatora došao. Ova vrsta napada obično se naziva krađa sjednice (engl. Session Hijacking). [10] Npr. možda algoritam za generiranje sjedničkog identifikatora jednostavno generira novi sjednički identifikator povećavanjem vrijednosti prethodnog sjedničkog identifikatora. Kako bi napadač u ovom slučaju proveo napad krađe sjednice dovoljno je da napravi sljedeće:

• U prvom koraku napadač pristupa Web aplikaciji kako bi dobio trenutni sjednički identifikator.
• U drugom koraku Web aplikacija napadaču šalje trenutni sjednički identifikator (npr. sjednički identifikator koji ima vrijednost 10001). Napadač nakon što dobije sjednički identifikator izračunava vrijednost novog, sljedećeg, sjedničkog identifikatora, jednostavno povećavanjem vrijednosti trenutnog sjedničkog identifikatora ili korištenjem metoda za grubo pretraživanje.
• U trećem koraku napadač nakon uspješnog izračunavanja novog sjedničkog identifikatora (10002) pristupa sadržaju Web aplikacije koristeći izračunati sjednički identifikator. (Slika 3.39)

Jedna od ranjivosti kontrole sjednice je i predugo vrijeme trajanja sjednice. Zbog predugog trajanja korisničke sjednice Web aplikacija se još više izlaže riziku kod napada krađe sjednice. Kraće vrijeme trajanja sjednice neće spriječiti napadača da dođe u posjed sjedničkih identifikatora (npr. iskorištavanjem ranjivosti na XSS napade ili prisluškivanjem mrežnog prometa), ali će onemogućiti dugotrajno i uzastopno korištenje ukradenih sjedničkih identifikatora. Problem predugog trajanja sjednice javlja se i u otvorenim radnim okolinama (npr. Internet kavana, knjižnica i sl.). Ukoliko se korisnik koji radi u takvoj radnoj okolini propisno ne odjavi s Web aplikacije, otvara se mogućnost da ostali korisnici mogu pristupiti njegovim korisničkim računima koje je koristio. Predugo trajanje sjednice također povećava i vjerojatnost da napadač uspješno pogodi sjednički identifikator.

Loše programsko ostvarenje procesa odjave korisnika (engl. logout) s Web aplikacije isto predstavlja ranjivost kontrole sjednice. Ranjivost se javlja ako se nakon odjave korisnika ne unište svi podaci vezani uz sjednicu i sjednički identifikator. Ako je napadač došao u posjed sjedničkog identifikatora, kod ispravnog programskog ostvarenja odjave korisnika nakon što se korisnik odjavi napadač od tog sjedničkog identifikatora nema nikakve koristi. U slučaju lošeg programskog ostvarenja odjave korisnika napadač se i dalje može koristiti s tim sjedničkim identifikatorom za pristupanje sadržaju Web aplikacije, jer korisnička sjednica nije uništena. [12]

Još jedna vrsta napada na kontrolu sjednice je i fiksacija korisničke sjednice (engl. Session Fixation). [10] Ranjivosti vezane uz fiksaciju sjednice obično se pojavljuju kod Web aplikacija koje stvaraju anonimnu korisničku sjednicu za svakog korisnika koji prvi puta pristupi Web aplikaciji. Obično kod takvih Web aplikacija anonimna korisnička sjednica nakon prijave korisnika na Web aplikaciju postaje autentificirana korisnička sjednica. Napadač može iskoristiti ovakvo ponašanje Web aplikacije kako bi namjestio (fiksirao) korisničku sjednicu proizvoljnom korisniku i iskoristio tu sjednicu za pristup Web aplikaciji nakon što se korisnik prijavi na Web aplikaciju. Proces fiksacije sjednice može se prikazati kroz 4 koraka (Slika 3.40). Koraci koji opisuju proces fiksacije sjednice su:

• Korak 1: Pribavljanje anonimne sjednice

  U prvom koraku napadač pribavlja anonimnu sjednicu za pripadnu Web aplikaciju, odnosno sjednički identifikator koji će koristiti u napadu. Općenito postoje dva načina upravljanja sa sjedničkim identifikatorima. Kod prvog načina Web aplikacija prihvaća da joj korisnici (Web preglednik) prilikom prvom pristupanja sami zadaju sjednički identifikator, pa ih aplikacija raspoznaje po tom sjedničkom identifikatoru. Kod drugog načina Web aplikacija ne prihvaća korisnički generirane sjedničke identifikatore, nego sama generira sjedničke identifikatore i samo njih prihvaća. Ako se radi o prvom načinu, napadač ne mora niti pristupiti Web aplikaciji, nego sam generira proizvoljni sjednički identifikator koji će koristiti u napadu. Ako se radi o drugom načinu, napadač pristupa Web aplikaciji (npr. zatraži Web stranicu za prijavu /login.php) kako bi dobio anonimni sjednički identifikator koji će koristiti u napadu.

• Korak 2: Slanje pribavljene anonimne sjednice korisniku

  U drugom i ključnom koraku napadač korisniku šalje pribavljeni sjednički identifikator i navodi ga da se s tim sjedničkim identifikatorom prijavi na Web aplikaciju. Postoji nekoliko tehnika s kojima napadač može korisniku poslati pribavljeni sjednički identifikator, a one se razlikuju prema tome na koji način Web aplikacija koristi i prenosi sjedničke identifikatore. Dvije najuobičajenije tehnike su:

  • Ako Web aplikacija koristi URL za prijenos sjedničkog identifikatora, odnosno ako se sjednički identifikator prenosi kao vrijednost parametra unutra URL-a, napadač korisniku jednostavno može poslati taj URL (npr. https://www.primjer.com/login.php?SessId=12d1a1f8) i navesti ga da ga pokrene ili klikne na njega.
  • Ako Web aplikacija za prijenos sjedničkog identifikatora koristi HTTP kolačiće ili skrivena polja, napadač korisniku može poslati sjednički identifikator iskorištavanjem XSS ranjivosti unutar neke Web aplikacije.

• Korak 3: Prijava korisnika na Web aplikaciju koristeći fiksiranu sjednicu

  U trećem koraku korisnik ne znajući koristi fiksiranu sjednicu za prijavu na Web aplikaciju i time omogućava napadaču da pristupi njegovom sadržaju Web aplikacije.

• Korak 4: Napadač koristi fiksiranu sjednicu za pristup sadržaju Web aplikacije

  Cijelo vrijeme napadač periodički provjerava je li se korisnik prijavio na Web aplikaciju pristupajući zaštićenom sadržaju Web aplikacije koristeći fiksirani sjednički identifikator. U trenutku kada se korisnik prijavi na Web aplikaciju i napadač dobiva pristup zaštićenom sadržaju. Nakon ovog koraka napadač može koristiti Web aplikaciju sa svim privilegijama koje ima korisnik kojem je fiksirao sjednicu.

3.2.8 Nesigurna kriptografska pohrana

Sve naprednije Web aplikacije imaju potrebu spremanja osjetljivih podataka kao što su npr. korisnička imena i lozinke, brojevi kreditnih kartica ili neki drugi važni podaci vezani uz korisnike i Web aplikaciju. Ti povjerljivi podaci obično se spremaju u baze podataka, direktno na tvrdi disk ili na neki drugi medij za pohranu podataka na poslužitelju. Kako bi se zaštitili ti podaci ne smiju se nikada spremati u čistom obliku nego se koristi enkripcija, te se podaci spremaju u kriptiranom obliku.

Najčešći razlozi koji dovode do otkrivanja osjetljivih podataka su:

• spremanje osjetljivih podataka u nekriptiranom obliku,
• korištenje kriptografskih algoritama iz kućne radinosti,
• neispravno korištenje jakih kriptografskih algoritama,
• korištenje dokazano slabih kriptografskih algoritama (npr. MD5, SHA-1, RC3, RC4 i dr.) i
• loše upravljanje s ključevima.

Kako bi se osigurala sigurna pohrana osjetljivih podataka najvažnije je osigurati da je sve što je potrebno da bude spremljeno u kriptiranom obliku i kriptirano. Isto tako jako je bitno i da je postupak kriptiranja ostvaren na ispravan način, da se koristi odgovarajući kriptografski algoritam i da je generiranje i spremanje ključeva obavljeno na siguran način.

Za otkrivanje propusta kod kriptografske pohrane ne postoje automatizirani alati koji bi mogli otkriti propuste u pohrani. Jedini siguran način za otkrivanje ove ranjivosti je analiza programskog koda. Analizom programskog koda moguće je provjeriti je li enkripcija primijenjena na ispravan i siguran način, te na taj način otkriti potencijalne ranjivosti. [11][14]

3.2.9 Nesigurna komunikacija

Nesigurna komunikacija nastaje kada se osjetljivi podaci između poslužitelja i klijenta prenose u nezaštićenom obliku. Svi osjetljivi podaci tijekom prijenosa preko računalne mreže moraju biti u kriptiranom obliku, kako bi se osigurao integritet i tajnost podataka. Ako se tijekom prijenosa takvih podataka ne koristi enkripcija podaci su izloženi i nezaštićeni na mreži.

Za prijenos osjetljivih podataka Web aplikacije koriste sigurnu verziju HTTP protokola HTTPS (engl. Hypertext Transfer Protocol Secure) protokol koji koristi SSL (engl. Secure Sockets Layer) za zaštitu podataka koji se prenose. Enkripciju je potrebno koristiti za prijenos osjetljivih podataka između korisnika i Web poslužitelja, ali isto tako i za prijenos osjetljivih podataka između glavnog poslužitelja i ostali poslužitelja na mreži (npr. između glavnog poslužitelja i baze podataka). Enkripcija se mora koristiti za prijenos svih podataka tijekom trajanja autentificirane korisničke sjednice. Kako se sa svakim HTTP zahtjevom šalje i sjednički identifikator, a u nekim slučajevima i korisničko ime i lozinka, potrebno je obavljati enkripciju prometa tijekom cijele sjednice, a ne samo tijekom prijave korisnika na Web aplikaciju. Ukoliko se za prijenos osjetljivih podataka ne koristi enkripcija dobro pozicionirani napadač prisluškivanjem mreže, žične ili bežične, može doći u posjed tih osjetljivih podataka. U tom slučaju napadač može doći u posjed korisničkog imena i lozinke, korisničkog sjedničkog identifikatora, korisničkog bankovnog računa, broja kreditne kartice i sl., te na taj način ugroziti sigurnost Web aplikacije i korisnika.

Potrebno je napomenuti da i ako se koristi enkripcija osjetljivih podataka tijekom prijenosa Web aplikacija je i dalje ranjiva na sve do sada spomenute ranjivosti. Enkripcija samo osigurava da se podaci sigurno prenesu preko računalne mreže, a ne štiti od ranjivosti unutar Web aplikacija i njihovog iskorištavanja.

Otkrivanje ove ranjivosti obično se svodi na to da se otkrije koristi li se sigurna komunikacija ili ne, odnosno koristi li se SSL enkripcija. Automatizirani alati lako mogu otkriti koristi li se SSL enkripcija za komunikaciju između poslužitelja i korisnika, te mogu pronaći ranjivosti vezane uz SSL. Enkripcija koja se koristi na poslužiteljskoj strani između glavnog poslužitelja i ostalih poslužitelja na mreži ne može se otkriti automatiziranim alatima. Analiza programskog koda može dovesti do otkrivanja nekih potencijalnih propusta u enkripciji na poslužiteljskoj strani. [11]

3.2.10 Neuspješna zaštita pristupa URL-u

Ponekada se sigurnost za neke elemente Web aplikacije osigurava samo s time da URL do tih elemenata nije objavljen javnosti. Programeri ponekada krivo pretpostavljaju da su sadržaj i funkcionalnosti Web aplikacije sigurni ako se skrivaju od javnosti, tj. ako ne postoji poveznica s Web aplikacije na taj skriveni sadržaj. Ostvarivanje sigurnosti skrivanjem (engl. security through obscurity), bez dodatne provjere prava pristupa, je loš pristup i u nekim slučajevima može dovesti do kompromitiranja Web aplikacije.

Za otkrivanje ove ranjivosti koristi se metoda prisilnog pretraživanja Web sadržaja (engl. forced browsing) kako bi se otkrio skriveni sadržaj Web aplikacije. Metoda pogađanjem naziva sadržaja pokušava pronaći skriveni sadržaj kao što su direktoriji i datoteke. Osim pokušaja pogađanja imena direktorija i datoteka obično se provodi i slijepo pretraživanje u potrazi za uobičajenim nazivima direktorija i datoteka. Neki od uobičajenih naziva direktorija su npr./system/, /password/, /logs/, /admin/, /administrator/, /test/, /backup/ i dr. Promjenom ekstenzije postojećim datotekama pokušavaju se pronaći skrivene datoteke kao što su privremene datoteke i datoteke koje služe kao sigurnosne kopije. Neka npr. na poslužitelju postoji datoteka admin.jsp mijenjanjem ekstenzije (npr. admin.jsp.bak, admin.bak, admin.jsp.old) ili dodavanjem nekog znaka na kraj imena datoteke (npr. admin.jsp~) postoji mogućnost da se otkrije skrivena datoteka.

Automatizirani alati korištenjem metode prisilnog pretraživanja mogu pronaći skriveni sadržaj, ali ne mogu odrediti je li pronađeni sadržaj trebao biti zaštićen dodatnom kontrolom pristupa. Nakon što automatizirani alati pronađu sadržaj potrebno je ručno provjeriti je li pristup tom sadržaju trebao biti zaštićen.

Kako bi se spriječilo pojavljivanje ove ranjivosti potrebno je provesti dobru kontrolu pristupa nad cijelim sadržajem i funkcionalnostima Web aplikacije nebitno bili oni skriveni od javnosti ili ne. [11][12]