
Web sve viÅ¡e stasava u najrasprostranjeniju aplikacijsku platformu na svijetu. Koristeći web-browser imamo osjećaj da viÅ¡e ne koristimo web-stranicu, nego neki program, pa se tako mijenjaju i naÅ¡a oÄekivanja prema aplikaciji, navike koriÅ¡tenja, ali i budnost i zdrava sumnjiÄavost koju smo nekoć imali u radu sa webom, dok je joÅ¡ bio „samo“ web.
Od internetskog bankarstva, pa do druÅ¡tvenih mreža sve je viÅ¡e mjesta na kojima prepuÅ¡tamo nepoznatom krajnjem korisniku da u naÅ¡ informatiÄki sustav zapisuje vlastiti sadržaj. Korisnik nam je pri tome potpuno nepoznat; ne znamo njegove vjeÅ¡tine rada na raÄunalu, njegovu dobronamjernost, njegovu percepciju onoga Å¡to se od njega traži. Stoga Äudi, Å¡to se na tako mnogo mjesta korisniku dopuÅ¡ta odnosno vjeruje previÅ¡e.
Svako mjesto u kojem korisniku dajemo priliku da neÅ¡to upiÅ¡e, potencijalna je toÄka upada u vaÅ¡u web-aplikaciju, pa je zato nužna temeljita validacija unosa. U nedostatku resursa, developeri ponekad posežu za validacijom na klijentskoj strani, najÄešće pomoću JavaScripta. Sva takva rjeÅ¡enja to zapravo i nisu, jer upotrebom elementarnih web-developerskih alata, kao Å¡to su npr. dodatak za Firefox “Firebug” klijentska validacija nestaje kao gumicom obrisana. Kod validacije sa serverske strane, svaki podatak kojeg smo dobili od nepoznatog korisnika treba temeljito validirati prije nego Å¡to se nastavi s njegovom obradom. Iako su aplikacijski frameworkovi opremljeni raznim mehanizmima validacije, nije na odmet pristupiti i izradi vlastitih validacijskih alata i tehnika kako bi izbjegli ranjivost od eventualnih propusta u “defaultnim” rjeÅ¡enjima.
U vrijeme kada se javlja sve veći broj web-browsera, te ureÄ‘aja na kojima ih se koristi, dobra validacija unosa dodatno dobiva na znaÄenju, jer se nije moguće pouzdati u poznavanje specifiÄnih problematika jednog ili dvaju vodećih browsera.
Od svih korsniÄkih unosa posebno treba voditi raÄuna o tražilicama i poljima za unos formatiranog teksta. Tražilica, da bi bila funkcionalna mora podržavati elementarne logiÄke operatore – i/ili/ne, navodnike koji objedinju rijeÄi u izraze i sl. Tražilice po definiciji pretražuju; najÄešće bazu podataka koju ionako trebamo za prikaz sadržaja. MeÄ‘utim zlonamjerno postavljen upit može usporiti rad sve do uskraćivanja usluge (denial of service) ili izvrÅ¡iti vlastiti upit na bazu (code injection), a da ponekad pri tome niti ne bude zabilježen u logu kao neÅ¡to neobiÄno.
-
Polja za unos obogaćenog teksta vrlo su popularno i elegantno rjeÅ¡enje u razliÄitim aplikacijama u kojima je važan izgled korisniÄkog unosa. Za razliku od ostalih polja unosa, kod rich-text polja HTML tagovi su oÄekivani i propuÅ¡taju se, pa do izražaja dolazi vjeÅ¡tina i kreativnost napadaÄa i obrane. Jedni se svim silama trude razdvojiti dobronamjerni od zlonamjernog koda, dok drugi metodom pokuÅ¡aja i pogreÅ¡ke obrnutim inženjerstvom pronalaze naÄine da zaobiÄ‘u zaÅ¡tite prvih. Kako je nemoguće algoritamski utvrditi namjeru upotrebe odreÄ‘enog elementa, na softverskim arhitektima je zadatak minimaliziranja broja dopuÅ¡tenih tagova i atributa, uz predviÄ‘anje Å¡to viÅ¡e potencijalnih smjerova napada.
U tom kontekstu, važno je i testiranje aplikacije, u kojem je ne treba “Å¡tediti”, već se staviti u položaj napadaÄa, i koriÅ¡tenjem njihovih znanja i tehnika etiÄkim hakiranjem provjeriti i najneznatnije korisniÄke unose, a ne samo zadovoljiti se floskulom “Ma tko će to ići raditi!”. Samo tako web-aplikacija može postići razinu sigurnosti i pouzdanosti koja se oÄekuje od lokalnih aplikacija, Å¡to je nužan infrastrukturni preduvijet u trenutku ekspanzije web-aplikacija.
0 Komentari za ovaj tekst
1 Trackbacks za ovaj tekst
September 23rd, 2009 at 09:26
[...] imate podatke o vašim pretplatnicima, CRM, automatiziranu prodaju, podršku korisnicima… Jeste li integrirali te sustave u moćan e-mail marketinški sistem? Primjerice, korištenjem [...]
Vas Komentar