SQL injection: Sta sve treba da zastitim?
Hm, podstaknut knjigom koju čitam kad imam slobodnog vremena (što je retko), razmišljam pomalo i o bezbednosti aplikacije. Trenutno, pošto prelazim u svojoj glavi deo oko unosa i izmene podataka, razmišljam šta je sve potrebno da zaštitim.
Generalno gledano štitim "polja" kad unosim login podatke, ili bile koje polje za unos koje korisnik moze da koristi (pretraga, unosi podataka, login itd...) Meni je trenutno logicno da nema potrebe da proveravam silna polja prilikom unosa podataka od strane ovlascene osobe, jer ona mi ni ne zeli zlo. Ako je neko vec provalio user/pass preko onih polja koja ja kao inace štitim, bzv je da se dalje štitim zar ne?... P.S. Ja trenutno razmisljam u fazonu da je SQL injection napad preko nekog input polja gde umesto normalnog unosa, on bukvalno unosi zamaskiran kod (\). Ako grešim ispravite me! Ako mogu neki generalni saveti i iskustva (eventualno linkovi ka nekim zaista odlicnim tekstovima, mada na netu ima svasta...) Hvala :1043: |
Citat:
|
Veruj mi ima potrebe da sve proveravash.
Ajde saljem ti PM u toku dana sa detaljnim objashnjenjem. |
^ ako može to detaljno objašnjenje takođe na pm, ili na forum ? thx!
proučavao sam tu problematiku, ali uvek može da se nauči nešto novo. |
Malo detaljnije...
==- Ubrizgavanje SQL koda -==
SQL injection se zasniva na neautorizovanom i uglavnom malicioznom menjanju samog sql querija bez potrebe da sam napadac ima pristup izvornom kodu same aplikacije. Iako je nacinjena zashtita od sql injection napada u samom autorizacionom delu aplikacije, ukoliko neki drugi parametar nije sanitizovan, to znaci da ce napadac i dalje moci da nedozvoljeno menja podatke, i eventualno dobije vece privilegije od onih koje trenutno ima na sistemu. Posto uglavnom teoriju niko ne voli, prelazimo odmah na prakticni deo :) Primer: Dakle imamo tabelu korisnici, koja ima tri polja. Kôd:
+-----------+----------------------+-----------------+ index.php PHP kôd:
e sada ukoliko imamo sledeci zahtev na skriptu koju smo malo pre napravili Kôd:
http://www.example.com/index.php?uname=admin&passwd=123456 Kôd:
select * from korisnici where uname='admin' and pass='123456' bilo koje vrednosti na bilo kom parametru mi direktno menjamo query. Kôd:
http://www.example.com/index.php?uname='admin&passwd=123456 Kôd:
select * from korisnici where uname= ''admin' and pass='123456' jer queru nije ispravan. Ali shta ce biti ukoliko prosledimo sledece parametre nasoj skripti.. Kao username stavimo Kôd:
' OR '1'='1 dobijamo sledeci query. Kôd:
select * from korisnici where uname= '' OR '1'='1' and pass='' OR '1'='1' Uspeli smo da se logujemo na sistem bez ikakvih znanja o korisnickom imenu i sifri. Uglavnom je prvi zapis u tabelama za autorizaciju korisnicko ime administratora, dobijemo dakle administratorske privilegije. Posto trenutno nemam vremena da opsirnije obradim ovu temu, shto se tice zashtite pominjem samo to da treba proveravati svaku vrednost koju korisnik prosledi skripti, koristeci neke predefinisane funkcije kao shto je mysql_safe_escape_string() ili koristiti neka pravila (regularne izraze) da bi ste osigurali da korisnik unosi ispravne podatke. Off Topic: Posto uskoro registrujem firmu, koja ce se baviti sigurnoshcu, kada zavrshim svu papirologiju, organizovacu neki brifing vezan za ovu temu. U svakom slucaju vise detalja ce biti objavljeno kada sve bude pripremljeno. Pozdrav. |
Citat:
|
Nije dovoljno koristiti samo mysql_real_escape_string jer u odredjenim situacijama (visestruki kveriji u jednom pozivu funkcije) je moguce zaobici ovaj vid zastite ...
Npr: PHP kôd:
p.s. mysql_query() ne podrzava visetruke kverije u jednom pozivu ali npr u SQLlite i PostgreSQL funkcijama je ovo moguce izvesti. Sledeci problem je kod LIKE operatora, ukoliko imamo neke kverije koji rade pretrazivanje baze sa ovim operatorom i plus se sve to nalazi u petlji, moze doci do DoS napada na bazu. Tj ubacivanjem % ili _ karaktera u string koji se trazi moze se iskomplikovati upit i na taj nacin "pojesti" resurse mysql servera. Ovo nije slucaj na koji cesto nailazimo ali je dobro znati da mysql_real_escape_string ne eskejpuje % i _ karaktere, vec je potrebno uraditi ovo "rucno" (npr: str_replace). Ovo su samo par primera ima ih jos puno ali mislim da je dovoljno za pocetak :) Samo jos par napomena: - Nikad se ne oslanjajte na automatsko eskejpovanje (magic quotes) - Ukoliko je moguce koristite "prepared statement" metod: MySQL Improved Extension, ... |
provera tipa varijable, mod_secure, mysqli bind.
|
Citat:
Evo da rezimiram, za one sa jeftinijim ulaznicama :D 1. Ako je ikako moguce koristiti prepared statements. Ne samo sto je sigurnije, vec je i mnogo efikasnije kad se isti SQL izvrsava vise puta, samo se menjaju parametri. Mysql drajveri to ne podrzavaju, ali mysqli, pdo, postgres podrzavaju, tako da samo php4 + mysql kombinacija imaju problem. 2. Ako vozimo php4 i mysql (jos uvek najcesca varijanta) onda je potrebno uraditi sledece:
Ovde $a treba escapeovati samo sa mysql_real_escape_string, dok za $b moramo da koristimo i addcslashes i to je to... a evo i moja funkcija za escape koja mislim da lepo sljaka: PHP kôd:
|
i brojeve konvertovati u integer:
PHP kôd:
|
Citat:
|
Citat:
Citat:
|
Citat:
|
Citat:
|
Mozes malo da pojasnis sta si time hteo da kazes ?
|
Citat:
|
SQL injection cheat sheet
|
Vreme je GMT +2. Trenutno vreme je 19:07. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.