User Tools

Site Tools


business_logic

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
business_logic [2026/06/15 16:23] – formatiranje zakljucka mbunicbusiness_logic [2026/06/15 19:01] (current) – Dodavanje i promjena sadržaja poglavlja o mitigacijama mbunic
Line 61: Line 61:
 ===Prevencija business logic ranjivosti=== ===Prevencija business logic ranjivosti===
  
-Business logic ranjivosti uvelike ovise o kontekstu aplikacije, stoga je potrebno dobro razumijevanje logike sustava, njegovih funkcionalnosti i namjena pri razvoju i implementaciji sustavapogotovo kada više ljudi zajedno rade na razvoju. Kada jedna osoba radi na jednoj komponenti sustava koja je povezana s drugom komponentom koju razvijaju drugi programeri, mora dobro razumjeti obje komponente i njihovu namjenu te predviđene funkcionalnosti. Zato je važno tijekom razvoja sustava imati dobro dokumentirane namjene i funkcionalnosti pojedinih komponenti.+Business logic ranjivosti uvelike ovise o kontekstu aplikacije, stoga je potrebno dobro razumijevanje logike sustava, njegovih funkcionalnosti i namjene pri razvoju i implementaciji, osobito kada više ljudi zajedno radi na sustavu. Kada jedna osoba radi na komponenti sustava koja je povezana s drugom komponentom koju razvijaju drugi programeri, mora dobro razumjeti obje komponente i njihovu namjenu te predviđene funkcionalnosti. Zato je važno tijekom razvoja sustava imati dobro dokumentirane namjene i funkcionalnosti pojedinih komponenti.
  
  
-Dakle, tijekom razvoja, osim posvećivanja pažnje sigurnosti koda, treba voditi računa i o mogućim zlonamjernim korisnicima koji će pokušati koristiti sustav na nepredviđene načine. Treba primijeniti validacije korisničkog unosa provjere stanja sustava i njegovih vrijednosti, sa što strožim ograničenjima, kako ne bi bilo moguće koristiti sustav izvan predviđenih granica.+Dakle, tijekom razvoja, osim posvećivanja pažnje sigurnosti koda, treba voditi računa i o mogućim zlonamjernim korisnicima koji će pokušati koristiti sustav na nepredviđene načine. Treba primijeniti validaciju korisničkog unosa te provjere stanja sustava i njegovih vrijednosti uz precizno definirana ograničenja, kako ne bi bilo moguće koristiti sustav izvan predviđenih granica.
  
-Na primjer ako je očekivani korisnički unos e-mail adresamogu se koristiti već gotove implementacije koje provjeravaju da je uneseni e-mail validan i da ne sadržava nikakve znakove niti određene redoslijede dopuštenih znakova koji se ne mogu koristiti e-mail adresi.+Na primjerako je očekivani korisnički unos cijeli broj u rasponu od 1 do 9treba osigurati da su samo te vrijednosti dopuštene, dok se ostali unosi odbacuju uz odgovarajućgrešku.
  
-Ako je očekivani korisnički unos cijeli broj u rasponu od jedan do devettreba provjeriti da je korisnički unos cijeli jednoznamenkasti broj rasponu od jedan do devet, a za ostale javiti pogrešku.+Ako je očekivani korisnički unos nešto složenijiprimjerice IBAN, mogu se koristiti gotove implementacije koje provjeravaju je li unos u validnom formatu i ne sadrži nedopuštene znakove ili kombinacije znakova.
  
-Važno je voditi računa da ove provjere nije dovoljno implementirati samo na korisničkoj strani, npr. korištenjem client-side JavaScript koda, jer se zahtjevi mogu jednostavno modificirati prije slanja, a provjere na korisničkoj strani zaobići. Potrebne su provjere korisničkog unosa na serverskoj straniprilikom samog korisničkog unosa, a poželjno na dubljim daljim dijelovima procesa obrade i posluživanja podataka.+Također, sama validacija korisničkog unosa nije dovoljna, nego je potrebno i provjeriti relevantan kontekst stanja sustava te poslovna pravila koja određuju je li određena radnja dopuštena. Na primjer, korisnik može unijeti valjan iznos novca koji želi poslati, ali za izvršenje transakcije mora imati dovoljno sredstava na računu. 
 + 
 +Važno je imati na umu da ove provjere nije dovoljno implementirati samo na klijentskoj strani, npr. korištenjem client-side JavaScript koda, jer se zahtjevi mogu jednostavno modificirati prije slanja zaobići provjere na klijentskoj strani. Potrebne su provjere korisničkog unosa na serverskoj strani prilikom unosa podatakakao u kasnijim fazama njihovog korištenja i obrade.
  
 Izvori:\\ Izvori:\\
business_logic.1781540617.txt.gz · Last modified: 2026/06/15 16:23 by mbunic

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki