23. 05. 2012. | #1 |
novi član
Na probnom radu
Datum učlanjenja: 17.05.2012
Poruke: 18
Hvala: 4
0 "Hvala" u 0 poruka
|
Codeigniter 2.0 i bezbednost
Pozdrav svima,
Pravim aplikaciju u CI. Mislio sam da je dovoljno da u config.php stavim TRUE kod dela XSS, ali sada vidim da on stiti samo od nekih reci kao sto su "<script>" ili "<?php", itd. a ne recimo za SQL napad. Da li koristite php-ove funkcije htmlspecialshars, mysql_real_escape_string,.... ili koristite neke klase ili samo ono sto pruza CI za opstu bezbednost ? Sta je savet vas profesionalaca? |
23. 05. 2012. | #2 |
expert
Grand Master
Datum učlanjenja: 11.04.2010
Poruke: 998
Hvala: 141
959 "Hvala" u 153 poruka
|
PHP je nesiguran, CI je veoma loš, mysql_* je deprecated, a ti trebaš koristiti PDO ili MySQLi. Ne postoji silver bullet koji štiti protiv SQL, magic_quotes su bile uvedene za to, i to je bio fail.
|
23. 05. 2012. | #3 |
novi član
Na probnom radu
Datum učlanjenja: 17.05.2012
Poruke: 18
Hvala: 4
0 "Hvala" u 0 poruka
|
Ja koristim Active Record Class u CI, sto se tice upita, mada CI tvrdi da koristeci te funkcije vec imamo sigurnost al ti me sad naplasi...
|
23. 05. 2012. | #4 |
expert
Grand Master
Datum učlanjenja: 11.04.2010
Poruke: 998
Hvala: 141
959 "Hvala" u 153 poruka
|
Nećeš imati problema, ne znam kako Active Record radi da bih mogao nešto pametovati, ali u svakom slučaju to je abstrakcija, vjerovatno za mysql_*, čak i ako koristiš PDO, ako nije PDO::ATTR_EMULATE_PREPARES podešen na false, ima teoretske šanse da je nesiguran.
Ne moraš ništa da koristiš od funkcija koje si naveo, ali uradi validaciju podataka bez obzira na SQL injection. Znači ako je nešto broj, ne dopuštaj ništa osim 0-9. Ja bih zaobišao CI, pogledaj Kohana, Lithium, Zend, FuelPHP... |
24. 05. 2012. | #5 |
novi član
|
Ja se necu osvrtati na ovo sto ti je webarto rekao - pre svega zato sto je u pravu. Dakle ako hoces zaista bezbednu aplikaciju batali CI-ev AC! On se ne oslanja ni na PDO ni na MySQLi nego je maltene Query generator. Bar koliko sam ga ja za ove 2 godine aktivnog koriscenja upoznao. Sa druge strane - mozes da uzmes neki ORM (Propel, Doctrine) i da sve operacije nad bazom radis preko njega.
Elem, da dam odgovor na tvoje konkretno pitanje. Ako ukljucis XSS u config-u CI-a on ce te "zastiti" samo od XSS napada u smislu da ce svaki input filtrirati kao sto si i sam rekao od tagova tipa "<script>" itd... (vise o tome). Naravno ovde je obavezno koriscenje njegove Input klase. Ukoliko pristupis direktno $_POST-u npr. dzaba ti ukljucen XSS. Kad je zastita od SQL injection-a u pitanju - ako ostanes pri tome da koristis CI-ev AC - ponasaj se kao da nema nikakvu zastitu i radi kao da radis sa PHP native mysql_* funkcijama. Kazem uradice on escape ali ne oslanjaj se preterano na to... Nadam se da sam pomogao, ako sam pogresio ispravice me neko od iskusnijih clanova. |
24. 05. 2012. | #6 |
novi član
Na probnom radu
Datum učlanjenja: 17.05.2012
Poruke: 18
Hvala: 4
0 "Hvala" u 0 poruka
|
OK, samo koliko vidim ako nastavim ovako kako sam poceo (a moram), najbolje je za SQL (recimo) koristiti
mysql_real_escape_string Ovo podrzava php5 i ne vidim da ima nesto drugo (van PDO, doctrine, itd), znaci gledam kao dodatak za CI i Active Record Class. @ webarto ja sam te nesto pogresno skontao, ova funkcija nije deprecated, jer ne vidim neku zamenu. Jesu klasicne deprecated mysql_ jer se akcenat baca na mysqli_ |
24. 05. 2012. | #7 |
Pukovnik u penziji
Grand Master
|
Pdo
|
24. 05. 2012. | #8 |
Ivan Dilber
Sir Write-a-Lot
|
mysql_real_escape_string() je funkcija koja radi escaping specijalnih znakova uz proveru enkodinga, tako da ti garantuje da specijalni znaci nece zeznuti upit kad ga kreiras u obliku SQL stringa. To je sasvim sigurna metoda ako pazljivo programiras i znas sta radis.
S druge strane kad koristis prepared statements preko PDO ili mySqli extenzija onda ne moras da brines o escape-ovanju podataka, jer se postupak kreiranja upita sastoji iz 2 koraka: prvo se kompajlira SQL, pa se tek onda prosledjuju podaci. Tako drajver za bazu zna koji tip podataka ocekuje i ako mu posaljes pogresan bacice gresku. To je zgodnije za rad i sigurnije (ne zato sto drugi metod ne radi, nego u smislu da su manje sanse da nesto previdis). Naravno i sa prepared statements mozes da pises nesigurne upite, zato je bitno da proucis putstvo i shvatis mehaniku kako to radi. Kad koristis apstrakcije iz frameworka onda si u problemu jer je ta mehanika sakrivena od tebe i nemas pojma sta se desava, mozes samo da se nadas da je onaj koji je to pisao znao sta radi... ali je zato lakse za rad, pa ti sam onda odmeris kojim putem zelis da ides...
__________________
Leadership is the art of getting people to want to do what you know must be done. |
24. 05. 2012. | #9 |
expert
Grand Master
Datum učlanjenja: 11.04.2010
Poruke: 998
Hvala: 141
959 "Hvala" u 153 poruka
|
^ ili možeš da pregledaš source...
mysql_real_escape_string() ne escapuje backtick, tako da se može ovo uraditi, vidjao sam slučajeve, ali rijetko... SELECT * FROM `users` WHERE `username` = `admin` AND `password` = `1` OR 1 = 1;--` |
28. 05. 2012. | #10 |
Wait, What?
Qualified
Datum učlanjenja: 21.03.2010
Poruke: 148
Hvala: 8
188 "Hvala" u 14 poruka
|
a nesto ovako da se stavlja addcslashes($value, "\x00\n\r\'\x1a\x3c\x3e\x25") ?
__________________
Svakog dana uvlacim linije pa misle da se drogiram. |
|
|