DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   Codeigniter 2.0 i bezbednost (http://www.devprotalk.com/showthread.php?t=11021)

etelteam 23. 05. 2012. 17:34
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?

webarto 23. 05. 2012. 19:29
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.

etelteam 23. 05. 2012. 22:46
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...

webarto 23. 05. 2012. 22:57
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...

Nemanja89 24. 05. 2012. 00:27
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.

etelteam 24. 05. 2012. 11:59
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_

mangia 24. 05. 2012. 13:20
Pdo

ivanhoe 24. 05. 2012. 15:52
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...

webarto 24. 05. 2012. 16:08
^ 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;--`

squirll 28. 05. 2012. 14:02
a nesto ovako da se stavlja addcslashes($value, "\x00\n\r\'\x1a\x3c\x3e\x25") ? :)

etelteam 29. 05. 2012. 20:57
Ovako imam ponudjeno resenje od kolege ali nisam siguran dal je dobro.
Iako sam testirao AR u CI i radi, ipak bih dodao i

mysql_real_escape_string()

Kolega se dosetio i napravio svoju klasu koja nasledjuje Input klasu. I tu ce ubaciti ovu funkciju, pa ce obaviti validaciju jos u kontroleru.

Ja sam do sad znao pravilo da se validacija i zastita od SQl napada vrsi pre samog upisa u bazu (znaci u model). A kolega kaze da nece da skodi i da ce ovako biti lakse. Zanima me koliko je dobar ovaj nacin, vrsenja validacije kroz input klasu...? (kako za CI primer ali i generalno)
a to je ova klasa:

http://codeigniter.com/user_guide/libraries/input.html

Naravno imamo i ovde CI pravilo, pa je kolega uzeo Input klasu zbog toga...
Citat:
The Database classes can not be extended or replaced with your own classes. All other classes are able to be replaced/extended.
Zaboravih da dodam da bi ova klasa imala argument (tipa zelis ciscenje ili ne), tako da bi mogao da vrsis validaciju ili ne zelis, cisto da ne bude da ce uvek biti validacije, vec od slucaja do slucaja.

etelteam 30. 05. 2012. 19:14
Evo sta se desava u Active Record Class u CI

Kôd:
/**
        * "Smart" Escape String
        *
        * Escapes data based on type
        * Sets boolean and null types
        *
        * @access        public
        * @param        string
        * @return        mixed
        */
        function escape($str)
        {
                if (is_string($str))
                {
                        $str = "'".$this->escape_str($str)."'";
                }
                elseif (is_bool($str))
                {
                        $str = ($str === FALSE) ? 0 : 1;
                }
                elseif (is_null($str))
                {
                        $str = 'NULL';
                }

                return $str;
        }
Kôd:
/**
        * Escape String
        *
        * @access        public
        * @param        string
        * @param        bool        whether or not the string will be used in a LIKE condition
        * @return        string
        */
        function escape_str($str, $like = FALSE)
        {
                if (is_array($str))
                {
                        foreach ($str as $key => $val)
                        {
                                $str[$key] = $this->escape_str($val, $like);
                        }

                        return $str;
                }

                if (function_exists('mysqli_real_escape_string') AND is_object($this->conn_id))
                {
                        $str = mysqli_real_escape_string($this->conn_id, $str);
                }
                elseif (function_exists('mysql_escape_string'))
                {
                        $str = mysql_escape_string($str);
                }
                else
                {
                        $str = addslashes($str);
                }

                // escape LIKE condition wildcards
                if ($like === TRUE)
                {
                        $str = str_replace(array('%', '_'), array('\\%', '\\_'), $str);
                }

                return $str;
        }
Meni ovo deluje sasvim solidno... Ne deluje bas nepouzdano.

ivanhoe 31. 05. 2012. 01:29
Citat:
Originalno napisao webarto (Napišite 107066)
^ 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;--`
Hmm, ajd proveri ti taj primer (ako sam ga dobro razumeo), jer backticks oko vrednosti 1 nije legalna sql sintaxa (sem ako imas polje u bazi koje se zove 1).

Taj napad bi mogao da se upotrebi ako je ime baze ili polja dinamicko i uzima se spolja bez provere, ali to je vec druga prica, jer te od toga ne stiti ni prepered statement. I tamo te vrednosti moraju da budu definisane u SQL-u prilikom prepare-ovanja, tako da bi to moglo da se hakuje na isti nacin.

etelteam 31. 05. 2012. 16:59
Citat:
Originalno napisao ivanhoe (Napišite 107244)
Hmm, ajd proveri ti taj primer (ako sam ga dobro razumeo), jer backticks oko vrednosti 1 nije legalna sql sintaxa (sem ako imas polje u bazi koje se zove 1).

Taj napad bi mogao da se upotrebi ako je ime baze ili polja dinamicko i uzima se spolja bez provere, ali to je vec druga prica, jer te od toga ne stiti ni prepered statement. I tamo te vrednosti moraju da budu definisane u SQL-u prilikom prepare-ovanja, tako da bi to moglo da se hakuje na isti nacin.
Citat iz CI dokumentacije... Posto ima veze sa diskusijom iako nije direktan odgovor na gornji post.

In many databases it is advisable to protect table and field names - for example with backticks in MySQL. Active Record queries are automatically protected, however if you need to manually protect an identifier you can use:
Kôd:
$this->db->protect_identifiers('table_name');

ivanhoe 31. 05. 2012. 17:59
mislim da se to odnosi na zastitu da slucajno ime polja nije neka rezervisana rec u SQL-u, npr. desava se da slucajno nazoves polje date ili timestamp. Ako ga stavis u backticks onda mozes da koristis kakav zelis naziv polja


Vreme je GMT +2. Trenutno vreme je 22:08.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.