Differences

This shows you the differences between two versions of the page.

--- race_condition [2025/02/10 15:41] – kresimir
+++ race_condition [2026/06/12 18:18] (current) – detalj mbunic
@@ Line 1: / Line 1: @@
-====Race condition====
+====Race condition u web aplikacijama====
-Race condition je tip ranjivosti, koji je se najčešće pojavljuje i koristi u web sustavima kao ranjivost, no može se pojaviti i u drugim kategorijama sustava i u kombinacijama  s drugim ranjivostima. Karakterizira ga tip izvedbe, gdje se skup dviju ili više akcija rade  uzastopno jedna za drugom s vrlo malim vremenskim razmakom između njih, koji se naziva „race window“ ili prozor utrke. Ciljevi i posljedice ovog tipa napada su razni, jer se ova ranjivost pojavljuje u mnogo oblika i u više različitih okruženja.
+**Race condition ranjivost u web aplikacijama** često je moguće iskoristiti za napad samo u određenom vremenskom prozoru ili pažljivo tajmiranim izvođenjem sekvenci akcija. Događa se kada nisu ostvarena odgovarajuća ograničenja i svojstva atomarnosti nad akcijama koje se izvršavaju nad određenim resursom. Zbog toga koordinacija dvaju ili više procesa (nekad i dretvi ili instanci istog procesa) nad istim resursom nije adekvatno vremenski usklađena ili je redoslijed izvršavanja akcija neispravan.
-Postoje mnogo različitih metoda kako bi se skup akcija za race condition izveo unutar ranjivog vremenskog perioda (eng. race window), koji je često jako malen, manji od sekunde. Od metoda koje serijski šalju velik broj akcija, jednu za drugom što većom brzinom, do metoda koje paralelno izvršavaju akcije, pa i do metoda koje koriste određene tehničke funkcionalnosti različitih protokola kako bi „dostavile“ skup akcija istovremeno žrtvi, iako zahtjevi ne moraju biti inicijalno generirani unutar kratkog vremenskog razmaka.
-Najjednostavniji primjer ovog napada jest iskorištavanje jednokratnog poklon bona ili koda za popust na web shopu više puta. Zamislimo da na serverskoj strani postoji sljedeća logika za iskorištavanje poklon bona: pri zahtjevu za korištenje bona, prvo se provjerava je li bon već iskorišten, ako nije onda se poklon bon dodaje u obračun i postavlja se zastavica da je poklon bon iskorišten. Vremenski prozor između ove dvije operacija, provjere je li poklon bon već iskorišten i dodavanja poklon bona u obračun te postavljanja zastavice jest vrlo mali, često u milisekundama. Ako prikladne mjere opreza nisu implementirane, taj vremenski prozor omogućava izvršavanje race condition ranjivosti. Ovisno o korištenom HTTP protokolu, šalje se veći broj zahtjeva ili paralelno ili serijski preko jedne konekcije uzastopno u velikom broju odgovarajućom tehnikom, s istim bonom. Nakon pristizanja prvog zahtjeva, vrši se provjera je li bon već iskorišten, ako nije, prelazi se na sljedeću operaciju obračunavanja bona i postavljanja zastavice. Istovremeno pristiže drugi zahtjev koji u trenutku provjeravanja zastavice prolazi provjeru jer se pri obradi prvog zahtjeva zastavica još nije postavila. Na kraju oba zahtjeva prolaze provjeru i isti bon se obračunava dva puta. Ovisno o ranjivom  vremenskom periodu (eng. race window), korištenoj tehnici i drugih karakteristika mreže i sustava, mogu i više od dva zahtjeva proći provjeru. Nakon što prođe vremenski period ranjivosti, ostali zahtjevi će biti odbačeni. Ovaj Napad je prikazan na slici 1.
-{{racecondition:slika1.png}}
-Jednostavne race condition ranjivosti uglavnom zahtijevaju slanje većeg broja istih zahtjeva unutar ranjivog vremenskog perioda i mogu se ostvariti korištenjem alata kao što su Burp Suite turbo Intruder ili Burp Suite Repeater stvaranjem skupa zahtjeva, te slanjem zahtjeva paralelno ili serijski, preko jedne konekcije. Isto tako se mogu napisati i vlastite skripte, od jednostavnih JavaScript skripti, koje se mogu u samoj konzoli web browsera pokrenut, do Python skripti ili Bash skripti.
+Jednostavan primjer za demonstraciju je sustav u kojem postoji memorijska lokacija koja sadrži zapis broja preostalih ulaznica.
-Složenije race condition ranjivosti mogu zahtijevati slanje više različitih zahtjeva na dvije ili više pristupne krajnje točke (eng. Endpoints) aplikacije. Na primjer istovremeno slanje koda za potvrdu e-mail adrese, pristiglog na prvu e-mail adresu zahtjeva za promjenu e-mail adrese, gdje bi se kao rezultat potvrdila promijenjena e-mail adresa sustava, kojoj napadač nema pristup. Također, nekad prisutnost race conditiona ne omogućuje iskorištavanje ranjivosti ili napad samo po sebi, ali se može kombinirati sa drugim ranjivostima kako bi se ostvario kompleksan napad.
+Jedan program ili njegova instanca pročita taj podatak, smanji ga za jedan i ponovno zapiše u istu memorijsku lokaciju.
-Primjer napada pri kojoj se kombiniraju više ranjivosti bi bila neka PHP aplikacija sa funkcionalnošću koja omogućava učitavanje (eng. Upload) slike na stranicu, koja se nakon učitavanja provjerava da nije zlonamjerna datoteka. Tip kombiniranih napada bi mogao biti uzastopno slanje dviju datoteka, prva koja je slika koja prolazi provjeru, a druga koja je zlonamjerna skripta koja omogućava shell pristup. Nakon što datoteka sa slikom prođe provjeru, zamjenjuje se zlonamjernom skriptom koja ostaje u sustavu. Kompliciraniji primjer napada bio slučaju gdje se poslana datoteka provjerava procesom koji traje pola sekunde, nakon čega se uklanja iz sustava, ali se u unutar tih pola sekunde zlonamjerna skripta može dohvatiti i pokrenuti na drugoj pristupnoj krajnjoj točki. Ovo je primjer korištenja race condition ranjivosti kako bi se omogućilo izvršavanje naredbi. Ovaj napad je prikazan na slici 2.
+Sve je u redu ako drugi program pročita taj broj nakon što je prvi zapisao novu vrijednost.
+Ali problem nastaje ako drugi program pročita taj broj prije nego prvi zapiše novu vrijednost. Tada će drugi zapisati svoj broj „preko“ već izmijenjenog broja. Evo slijeda:
+^ U memoriji piše ^ Prvi program ^ Drugi program ^
+|  4  | pročita 4  | |
+|  4  | | pročita 4  |
+|  4  | smanji 4 za jedan  | |
+|  3  | i zapiše 3  | |
+|  3  | | ne zna da je broj sada već smanjen na 3 i ne umanjuje za jedan od 3 već od 4  |
+|  3  | | pa ne zapisuje ispravnih 2, već zapisuje 3  |
-{{racecondition:slika2.png}}
+Race condition se ispravno izbjegava tako da prvi program mora prvo zabraniti pristup toj memorijskoj lokaciji, zatim pročita, promijeni i zapiše podatak u nju, i onda tek dozvoli da itko drugi pristupa tom resursu, toj memorijskoj lokaciji.
-===PRIMJER - Zadatak s Hacknite platforme – Formule (Ovo je Hackultet platofrma)===
+Race condition se najčešće pojavljuje i koristi u web sustavima kao ranjivost, no može se pojaviti i u drugim kategorijama sustava i u kombinacijama s drugim ranjivostima. Iskorištava se tako da se skup dviju ili više akcija rade uzastopno jedna za drugom s vrlo malim vremenskim razmakom između njih, koji se naziva „race window“ ili prozor utrke. Ciljevi i posljedice ovog tipa napada su razni, jer se ova ranjivost pojavljuje u mnogo oblika i u više različitih okruženja.
-<file>
+Postoji mnogo različitih metoda kako bi se skup akcija za race condition izveo unutar ranjivog vremenskog perioda (eng. race window), koji je često jako malen, manji od sekunde. Od metoda koje serijski šalju velik broj akcija, jednu za drugom što većom brzinom, do metoda koje paralelno izvršavaju akcije, pa i do metoda koje koriste određene tehničke funkcionalnosti različitih protokola kako bi „dostavile“ skup akcija istovremeno žrtvi, iako zahtjevi ne moraju biti inicijalno generirani unutar kratkog vremenskog razmaka.
-Jura je jako voli utrke pa je odlučio napraviti svoj web shop u kojem će prodavati stvari na temu formula i utrka. Za sad je dostupan samo jedan proizvod, dok još ne proširi svoju ponudu.
-Kako bi promovirao svoj web shop i potaknu ljude na kupnju, svim stvorenim računima Jura je odlučio dodijeliti 10 Eura i jednokratni popust za prvu kupnju od 25%.
-Iako na računu nemate dovoljno iznosa za kupovinu artikla, postoji li način da ga ipak uspješno kupite?
-</file>
-Čitajući tekst zadatka, mogu se primijetiti hintovi koji ukazuju na race condition. Tema zadatka su formule i utrke (Race), a cilj zadatka je kupiti artikl za koji nemamo dovoljno stanje na računu, no imamo bon koji možemo iskoristiti za 25% popusta.
+Najjednostavniji primjer ovog napada jest iskorištavanje jednokratnog poklon bona ili koda za popust na web shopu više puta. Zamislimo da na serverskoj strani postoji sljedeća logika za iskorištavanje poklon bona:
-Nakon iskorištavanja popusta, na kratko se prikaže prazna stanica s natpisom „Postavljanje popusta“, koja može naznačiti nekakvo među stanje sustava u kojemu se postavlja popust.
+  * pri zahtjevu za korištenje bona, prvo se provjerava je li bon već iskorišten,
-Nakon toga se ponovno prikazuje stranica, sa iskorištenim popustom od 25% i sniženom cijenom prikazanom na slici 3.
+  * ako nije onda se poklon bon dodaje u obračun i
+  * postavlja se zastavica da je poklon bon iskorišten.
-{{racecondition:slika3.png}}
+Vremenski prozor između ove dvije operacija, provjere je li poklon bon već iskorišten i dodavanja poklon bona u obračun te postavljanja zastavice jest vrlo mali, često u milisekundama. Ako prikladne mjere opreza nisu implementirane, u tom vremenskom prozoru moguće je iskoristiti race condition ranjivost. Ovisno o korištenom HTTP protokolu, odgovarajućom tehnikom šalje se veliki broj zahtjeva ili paralelno ili serijski preko jedne konekcije uzastopno, svi s istim bonom. Nakon pristizanja prvog zahtjeva, napadnuti program provjerava je li bon već iskorišten, ako nije, prelazi se na sljedeću operaciju obračunavanja bona i postavljanja zastavice. Istovremeno pristiže drugi zahtjev kojeg provjerava druga instanca napadnutog programa i odobrava provjeru jer u tom trenutku prvi zahtjev još nije postavio zastavicu da je bon iskorišten. Na taj način oba zahtjeva prolaze provjeru i isti bon se obračunava dva puta. Ovisno o ranjivom  vremenskom periodu (eng. race window), korištenoj tehnici i drugih karakteristika mreže i sustava, mogu i više od dva zahtjeva proći provjeru. Nakon što prođe vremenski period ranjivosti, ostali zahtjevi će biti odbačeni. Ovaj Napad je prikazan na slici 1.
-Gumbi „Iskoristi popust“ i „makni popust“ oba šalju POST request na istu putanju „/discount“, što može naznačivati da postoji „switch“ varijabla koja naznačuje je li popust postavljen ili nije, koja mijenja vrijednost pri izvršavanju akcije za postavljanje ili micanje popusta.
+{{  racecondition:slika1.png  }}
-Kako bi se testiralo je li ova funkcionalnost ranjiva na race condition, može se koristiti Burp Suite alat „Repeater“ za slanje više istovremenih zahtjeva paralelno ili serijski preko jedne ili više konekcija. Ovaj alat je opisan na ovom linku: https://portswigger.net/burp/documentation/desktop/tools/repeater/send-group
-Može se koristiti i drugi pristup, pisanja jednostavne JavaScript skripte koja će se izvršiti unutar konzole web preglednika. Ovaj pristup pruža manje mogućnosti, ali je dovoljan za jednostavne slučajeve, dok je u složenijim slučajevima bolje koristiti prethodno spomenuti alat.
-Oblik skripte je definiran sljedećim izrazom:
-<code>
-for (let i = 0; i < N; i++) { fetch("/discount",{method: "POST"}); }
-</code>
-Gdje je N broj uzastopnih zahtjeva koji se šalju. Ova skripta se može pokrenuti na stranici zadatka u konzoli web preglednika, pristupom razvojnih alata preglednika (F12). Prikazano na slici 4.
-{{racecondition:slika4.png}}
+Jednostavne race condition ranjivosti uglavnom zahtijevaju slanje većeg broja istih zahtjeva unutar ranjivog vremenskog perioda i mogu se ostvariti korištenjem alata kao što su Burp Suite turbo Intruder ili Burp Suite Repeater stvaranjem skupa zahtjeva, te slanjem zahtjeva paralelno ili serijski, preko jedne konekcije. Isto tako se mogu napisati i vlastite skripte, od jednostavnih JavaScript skripti, koje se mogu pokrenuti u samoj konzoli web browsera, do Python skripti ili Bash skripti.
-Nakon pokretanje skripte za N = 10 i osvježavanja stranica, iskorišteni popust je -175%, a cijena još veća nego prije. Ovo naznačuje da je race condition ranjivost prisutna. Prikazano na slici 5.
+Složenije race condition ranjivosti mogu zahtijevati slanje više različitih zahtjeva na dvije ili više pristupnih krajnjih točkaka (eng. Endpoints) aplikacije. Na primjer istovremeno slanje koda za potvrdu e-mail adrese, pristiglog na prvu e-mail adresu zahtjeva za promjenu e-mail adrese, gdje bi se kao rezultat potvrdila promijenjena e-mail adresa sustava, kojoj napadač nema pristup. Također, nekad prisutnost race conditiona ne omogućuje iskorištavanje ranjivosti ili napad sama po sebi, ali se može kombinirati s drugim ranjivostima kako bi se ostvario kompleksan napad.
-{{racecondition:slika5.png}}
+Primjer napada pri kojoj se kombinira više ranjivosti bi bila neka PHP aplikacija s funkcionalnošću koja omogućava učitavanje (eng. Upload) slike na stranicu, a koju nakon učitavanja provjerava da nije zlonamjerna datoteka. Tip kombiniranog napada bi mogao biti uzastopno slanje dviju datoteka, prva koja je slika koja prolazi provjeru, a druga koja je zlonamjerna skripta koja omogućava shell pristup. Nakon što datoteka sa slikom prođe provjeru, zamjenjuje se zlonamjernom skriptom koja ostaje u sustavu. Dok program provjerava prvu datoteku, učitana je i druga, pa će odobrenje za prvu datoteku vrijediti i za drugu, zlonamjernu.
-Uzevši u obzir da je prije pokretanja skripte, akcija pridružena putanji bila „Makni popust“, može se zaključiti da se ta akcija izvršila 8 puta, oduzimajući 200% popusta od originalnih 25%, rezultirajući krajnjim popustom od -175%.
+Kompliciraniji primjer napada bio bi u slučaju kad se poslana datoteka provjerava procesom koji traje pola sekunde, nakon čega se uklanja iz sustava, ali se u unutar tih pola sekunde ta datoteka, zapravo zlonamjerna skripta, može dohvatiti i pokrenuti na drugoj pristupnoj krajnjoj točki. Ovo je primjer korištenja race condition ranjivosti kako bi se omogućilo izvršavanje naredbi. Ovaj napad je prikazan na slici 2.
-Stvaranjem novog korisnika ponovno se dolazi do početnog stanja bez iskorištenog popusta gdje je akcija pridružena uz putanju „/discount“ postavljena na iskoristi popust. Prikazano na slici 6.
+{{  racecondition:slika2.png  }}
-{{racecondition:slika6.png}}
-Ponovnim pokretanjem skripte, uz N=4, u stanju sustava dok popust nije postavljen a predviđena akcija je postavljanje popusta, uspješno se upotrjebljuje popust od 25% 4 puta, rezultirajući popustom od 100%, nakon čega je cijena 0. Prikazano na slici 7.
-{{racecondition:slika7.png}}
-Pritiskom na gumb „Buy“ uspješno se izvršava kupnja i dobiva rješenje zadatka.
@@ Line 58: / Line 45: @@
 <file>
-Netko je hakirao stranicu za glasanje - pizza s ili bez ananasa? Nema drugog objašnjenja zašto bi pizza s ananasom imala više glasova.. Možeš li upotrijebiti svoje hakerske vještine i spasiti glasanje - učiniti da ispravna pizza (bez ananasa!!) pobijedi?
+Netko je hakirao stranicu za glasanje - pizza s ili bez ananasa? Nema drugog objašnjenja zašto bi pizza s ananasom imala više glasova. Možeš li upotrijebiti svoje hakerske vještine i spasiti glasanje - učiniti da ispravna pizza (bez ananasa!!) pobijedi?
 Dostupan ti je izvorni kod web aplikacije
 http://chal.platforma.hacknite.hr:13006
 </file>
 Uz zadatak je dostupan i izvorni kod zadatka.
-Pristupom stranici zadatka, prikazane su dvije opcije glasanja, pizza s ananasom i pizza bez ananasa. Nakon odabira jedne opcije pritiskom na gumb “Glasaj”, poveća se broj glasova te opcije, te nestane gumb za glasanje za to opciju, no ostaje gumb za promjenu glasa za drugu opciju. Prikazano na slici 8.
+Pristupom stranici zadatka, prikazane su dvije opcije glasanja, pizza s ananasom i pizza bez ananasa. Nakon odabira jedne opcije pritiskom na gumb “Glasaj”, poveća se broj glasova te opcije, te nestane gumb za glasanje za tu opciju, no ostaje gumb za promjenu glasa za drugu opciju. Prikazano na slici 8.
-{{racecondition:slika8.png}}
+{{  racecondition:slika8.png  }}
-Analizom HTML koda stranice u inicijalnom stanju (brisanjem kolačića, postavlja se u inicijalno stanje) koristeći razvojne alate web preglednika, vidi se oba gumba šalju POST request na putanju „/vote“, jedan s vrijednošću „pineapple“, drugi s vrijednošću „noPineapple“. Prikazano na slici 9.
+Analizom HTML koda stranice u inicijalnom stanju (brisanjem kolačića, postavlja se u inicijalno stanje) koristeći razvojne alate web preglednika, vidi se da oba gumba šalju POST request na putanju „/vote“, jedan s vrijednošću „pineapple“, drugi s vrijednošću „noPineapple“. Prikazano na slici 9.
-{{racecondition:slika9.png}}
+{{  racecondition:slika9.png  }}
-Analizom izvornog koda za glasanje na putanji „/vote“, vidi se da se koristi puno asinkronih funkcija kao „CekajObraduBazePodataka”  i “ZbrajajGlasove”  koje se čekaju usred obrađivanja jednog zahtjeva glasanja. Ovo naznačuje da bi race condition ranjivost mogla biti prisutna. Prikazano na slici 10.
+Analizom izvornog koda za glasanje na putanji „/vote“, vidi se da se koristi puno asinkronih funkcija poput „CekajObraduBazePodataka”  i “ZbrajajGlasove”  koje se čekaju usred obrađivanja jednog zahtjeva glasanja. Ovo naznačuje da bi race condition ranjivost mogla biti prisutna. Prikazano na slici 10.
-{{racecondtion:slika10.png}}
+{{  racecondtion:slika10.png  }}
 Koristeći isti pristup stvaranja JavaScript skripte za slanje više uzastopnih zahtjeva, skripta je definirana u sljedećem izrazu:
@@ Line 83: / Line 70: @@
 }
 </code>
-Gdje je N broj uzastopnih zahtjeva koji će se slati. Pokretanjem ove skripte, sa N = 50, dok je sustav u inicijalnom stanju bez postavljenog glasa, uspješno se poveća broj glasova za pizzu bez ananasa za 6.
+Gdje je N broj uzastopnih zahtjeva koji će se slati. Pokretanjem ove skripte, s N = 50, dok je sustav u inicijalnom stanju bez postavljenog glasa, uspješno se poveća broj glasova za pizzu bez ananasa za 6.
 Ponovnim pokretanjem skripte, broj glasova se više ne mijenja. Detaljnijom analizom koda, vidi se da nakon što je jednom glas postavljen, ponovno slanje istog glasa izbacuje pogrešku, te ne može promijeniti sustav. Prikazano na slici 11.
-{{racecondition:slika11.png}}
+{{  racecondition:slika11.png  }}
-Znamo da je race window pri inicijalnom postavljanju glasa dovoljno velik da uspijemo broj glasova povećati za 6, naprednijim tehnikama i više, no potreban broj glasova da bi glasanje za pizzu bez ananasa pobijedilo je preko 200. Analizom koda za promjenu odabira glasa, vidi se da jest taj kod također ranjiv na race condition. Može se zaključiti da se postupak za dodavanje 200 glasova sastoji od slanja većeg broja glasova za željenu opciju, koji prolaze kroz race window te odabira druge opcije kako bi se opet omogućilo slanje novog skupa zahtjeva na željenu opciju koji će opet povećati broj glasova.
+Znamo da je race window pri inicijalnom postavljanju glasa dovoljno velik da uspijemo broj glasova povećati za 6, a naprednijim tehnikama i više, no potreban broj glasova da bi glasanje za pizzu bez ananasa pobijedilo je preko 200. Analizom koda za promjenu odabira glasa, vidi se da je taj kod također ranjiv na race condition. Može se zaključiti da se postupak za dodavanje 200 glasova sastoji od slanja većeg broja glasova za željenu opciju, koji prolaze kroz race window te potom odabira druge opcije kako bi se opet omogućilo slanje novog skupa zahtjeva na željenu opciju koji će opet povećati broj glasova.
-Kako bi to postigli, inicijalna skripta se mora proširiti sa još jednom for petljom, koja će nakon svakog slanja skupa zahtjeva za željenu opciju, poslati jedan zahtjev za drugu opciju, kako bi opet otvorilo mogućnost slanja novog skupa zahtjeva za željenu opciju. Modificirana skripta je prikazana u nastavku.
+Kako bi to postigli, inicijalna skripta se mora proširiti s još jednom for petljom, koja će nakon svakog slanja skupa zahtjeva za željenu opciju, poslati jedan zahtjev za drugu opciju, čime će opet otvoriti mogućnost slanja novog skupa zahtjeva za željenu opciju. Modificirana skripta je prikazana u nastavku.
-Znamo da je race window pri inicijalnom postavljanju glasa dovoljno velik da uspijemo broj glasova povećati za 6, naprednijim tehnikama i više, no potreban broj glasova da bi glasanje za pizzu bez ananasa pobijedilo je preko 200. Analizom koda za promjenu odabira glasa, vidi se da jest taj kod također ranjiv na race condition. Može se zaključiti da se postupak za dodavanje 200 glasova sastoji od slanja većeg broja glasova za željenu opciju, koji prolaze kroz race window te odabira druge opcije kako bi se opet omogućilo slanje novog skupa zahtjeva na željenu opciju koji će opet povećati broj glasova.
-Kako bi to postigli, inicijalna skripta se mora proširiti sa još jednom for petljom, koja će nakon svakog slanja skupa zahtjeva za željenu opciju, poslati jedan zahtjev za drugu opciju, kako bi opet otvorilo mogućnost slanja novog skupa zahtjeva za željenu opciju. Modificirana skripta je prikazana u nastavku.
 <code>
 for (let i = 0; i < M; i++) {
@@ Line 105: / Line 89: @@
 }
 </code>
-Gdje je broj N, broj slanja uzastopnih glasova za željenu opciju, a broj M broj ponavljanja skupa operacija koji se sastoji od slanja N zahtjeva na željenu opciju te odabira druge opcije kako bi se ponovno omogućilo poslati novi skup zahtjeva za željenu opciju.
+Gdje je broj N, broj slanja uzastopnih glasova za željenu opciju, a broj M je broj ponavljanja skupa operacija koji se sastoji od slanja N zahtjeva na željenu opciju te odabira druge opcije kako bi se ponovno omogućilo poslati novi skup zahtjeva za željenu opciju.
 Računajući da je N = 10, a M = 50, poslat će se ukupno 550 zahtjeva (500 zahtjeva za željenu opciju i 50 zahtjeva za drugu opciju). Zna se da će svaka skupina od 10 glasova za željenu opciju povećati broj glasova za 6, što bi uz 50 ponavljanja trebalo povećati broj ukupnih glasova za željenu opciju za otprilike 300.
-Nakon pokretanja ove skripte, broj glasova za pizzu bez ananasa je povećano iznad broja glasova za pizzu zadataka i zadatak je uspješno riješen, te je flag prikazan pri osvježavanju stranice.
+Nakon pokretanja ove skripte, broj glasova za pizzu bez ananasa je povećan iznad broja glasova za pizzu koje traži zadatak, čime je zadatak uspješno riješen, te je flag prikazan pri osvježavanju stranice.
@@ Line 118: / Line 102: @@
 ===Zaštita od race conditiona===
-Race condition ranjivost se može pojaviti u više oblika i u raznim funkcionalnostima, zato nema jednog rješenja koje se može primijeniti u svim situacijama, no najčešće rješenje je korištenje semafora i mutex zaključavanja pri korištenju kritičnih resursa. Mogu se koristiti ključevi za čitanje i ključevi za pisanje, gdje može istovremeno biti postavljeno više ključeva za čitanje na isti resurs, ali ključ za pisanje ne može biti postavljen istovremeno s drugim ključem za čitanje ili pisanje. Ovo rješenje ponekad može biti nepraktično, radi nepoželjnih karakteristika ili šanse da dođe do „deadlocka“, pa se ranjivost treba osigurati drugim načinom.
+Race condition ranjivost se može pojaviti u više oblika i u raznim funkcionalnostima, pa zato nema jednog rješenja koje se može primijeniti u svim situacijama, no najčešće rješenje je korištenje semafora i mutex zaključavanja resursa pri korištenju kritičnih resursa.
- Često su dostupna već gotova rješenja i biblioteke za resurse koji su predviđeni da se koriste u više-dretvenim okruženjima, jedan primjer je ConcurrentHashMap u Java programskom jeziku. Pri korištenju HashMap-a, koji se upotrebljava kao dijeljeni resurs između više dretvi, umjesto da dodatno implementiraju zaključavanja, može se koristiti dostupno rješenje koje je sigurno u više-dretvenim okruženjima.
-Također treba izbjegavati postepeno stvaranje objekata, gdje je objekt pri stvaranju u nedovršenom međustanju. Na primjer pri stvaranju novog korisnika u sustavu, prvo se izvodi jedna SQL transakcija za stvaranje dijela korisničkih podataka, onda se vrše druge operacije, pa se izvodi druga SQL operacija za stvaranje ostataka korisničkih podataka novog korisnika u bazi. Ovisno o funkcionalnostima, vremenski prozor između prve SQL transakcije gdje se stvara djelomični objekt i druge SQL transakcija nakon koje je objekt dovršen može otvoriti vrata nepredviđenom ponašanju i race condition ranjivosti. Umjesto toga, bolje je izvršiti cijeli proces stvaranja objekta u jednoj atomarnoj operaciji.
- Važno je biti svjestan postojanja ove ranjivosti pri pisanju koda, paziti na redoslijed i razmak između operacija za provjeravanje i korištenje resursa i napraviti odgovarajuće promjene dizajna ako se uobičajena i gotova rješenja ne mogu koristiti. Napisani kod se može kasnije analizirati alatima za statički analizu koda koji imaju mogućnost detekcije race conditiona te se ciljani dio koda također može testirati pod opterećenjem, je li ispravno funkcionira pri obrađivanju više paralelnih zahtjeva.
+Mogu se koristiti ključevi za čitanje i ključevi za pisanje, gdje može istovremeno biti postavljeno više ključeva za čitanje na isti resurs, ali ključ za pisanje ne može biti postavljen istovremeno s drugim ključem za čitanje ili pisanje. Ovo rješenje ponekad može biti nepraktično, radi nepoželjnih karakteristika ili šanse da dođe do „deadlocka“, pa se ranjivost treba ukloniti drugim načinom.
+ Često su dostupna već gotova rješenja i biblioteke za resurse koji su predviđeni da se koriste u više-dretvenim okruženjima. Jedan primjer je ConcurrentHashMap u programskom jeziku Java. Pri korištenju HashMap-a, koji se upotrebljava kao dijeljeni resurs između više dretvi, umjesto da dodatno implementiraju zaključavanja, može se koristiti dostupno rješenje koje je sigurno u više-dretvenim okruženjima.
+Također treba izbjegavati postupno stvaranje objekata, gdje je objekt tijekom stvaranja u nedovršenom međustanju. Na primjer, pri stvaranju novog korisnika u sustavu, prvo se izvodi jedna SQL transakcija za stvaranje dijela korisničkih podataka, onda se vrše druge operacije, pa se izvodi druga SQL operacija za stvaranje ostatka korisničkih podataka novog korisnika u bazi. Ovisno o funkcionalnostima, vremenski prozor između prve SQL transakcije gdje se stvara djelomični objekt i druge SQL transakcije nakon koje je objekt dovršen može otvoriti vrata nepredviđenom ponašanju i race condition ranjivosti. Umjesto toga, bolje je izvršiti cijeli proces stvaranja objekta u jednoj atomarnoj operaciji.
+Važno je biti svjestan postojanja ove ranjivosti pri pisanju koda, paziti na redoslijed i razmak između operacija za provjeravanje i korištenje resursa i napraviti odgovarajuće promjene dizajna ako se uobičajena i gotova rješenja ne mogu koristiti. Napisani kod se može kasnije analizirati alatima za statičku analizu koda koji imaju mogućnost detekcije race conditiona te se ciljani dio koda također može testirati pod opterećenjem, funkcionira li ispravno pri obrađivanju više paralelnih zahtjeva.