SQL injection: Sta sve treba da zastitim?

[[nq]]

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

[Dragi Tata]

Originalno napisao [nq]

Ako mogu neki generalni saveti i iskustva (eventualno linkovi ka nekim zaista odlicnim tekstovima, mada na netu ima svasta...)

Najbolji on-line tekst koji znam na tu temu: http://www.codeproject.com/cs/databa...ionAttacks.asp

[LiquidBrain]

Veruj mi ima potrebe da sve proveravash.

Ajde saljem ti PM u toku dana sa detaljnim objashnjenjem.

[phatsa]

^ 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.

[LiquidBrain]

==- 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.

    +-----------+----------------------+-----------------+
    |     ID    |   uname              |        pass     |
    +-----------+----------------------+-----------------+

Imamo sledeci deo koda u php-u.

index.php

PHP kôd:

<?php

   $username = $_GET['uname'];
   $passwd = $_GET['passwd'];
    

    $query = "select * from korisnici where uname = '$username' and pass = '$passwd'";
    $result =mysql_query($query);
    .
    .
    .
?>

Ostatak koda smo zanemarili.

e sada ukoliko imamo sledeci zahtev na skriptu koju smo malo pre napravili

http://www.example.com/index.php?uname=admin&passwd=123456

nama ce se izvr****i sledeci query:

  select * from korisnici where uname='admin' and pass='123456'

Kao shto vidite ovo je ispravan query. Medjutim, ukoliko stavimo jedan apostrof ispred
bilo koje vrednosti na bilo kom parametru mi direktno menjamo query.

http://www.example.com/index.php?uname='admin&passwd=123456

I u ovo slucaju dobijamo greshku jer query izgleda ovako:

  select * from korisnici where uname= ''admin' and pass='123456'

Primetite dva znaka apostrofa ispred admin. Naravno, sql server ce vratiti gresku,
jer queru nije ispravan. Ali shta ce biti ukoliko prosledimo sledece parametre
nasoj skripti..

Kao username stavimo

     ' OR '1'='1

i isto to za passwd parametar. Dakle
dobijamo sledeci query.

   select * from korisnici where uname= '' OR '1'='1' and pass='' OR '1'='1'

Dakle ispravan query, i to query koji vraca sve redove iz tabele korisnici.
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.

[misk0]

Originalno napisao [nq]

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!

Recimo search opcija na sajtu koja obicno radi 'where' na kraju SQL upita i onda iza toga dodas navodnike i .... voilaaaa

[Ivan]

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:

$id = "5; DELETE FROM users";
$id = mysql_real_escape_string($id);
mysql_query("SELECT * FROM users WHERE id={$id}"); 


U ovom slucaju mysql_real_escape_string nema nikakvu ulogu u zastiti nase skripte, vec je potrebno cast-ovati varijablu $id ( (int)$id ).

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, ...

[cvele]

provera tipa varijable, mod_secure, mysqli bind.

[ivanhoe]

Originalno napisao Ivan

mysql_query() ne podrzava visetruke kverije u jednom pozivu ali npr u SQLlite i PostgreSQL funkcijama je ovo moguce izvesti.

ok, tacno je to sto si rekao, mada je ovo kontradiktorna prica, posto sa SQLlite ili PGSQL-om svakako neces ni koristiti mysql_real_escape string

Evo da rezimiram, za one sa jeftinijim ulaznicama

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:

• mysql_real_escape_string - za obicne upite
• mysql_real_escape_string($sql) + addcslashes($sql, '%_') - za upite unutar LIKE izraza

Primer: SELECT * FROM tabela WHERE a=$a AND b LIKE '$b';
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:

/**
 * Escapes special characters in a string for use with mySQL queries 
 * WARNING: MySQL connection is required for this function !!  (or you'll get a E_WARNING and FALSE as the result)
 * @author Ivan Dilber (aka ivanhoe)
 * 
 * @param string $str String to be escaped
 * @param boolean $using_like Do we need to escape extra characters (% and _) for strings used inside LIKE expression
 * @return string
 */
function escape($str, $using_like=false) {
    if( get_magic_quotes_gpc() )  // if already escaped
            $str = stripslashes($str);
    $str = mysql_real_escape_string($str);

    return ( $using_like? addcslashes($str, '%_') : $str );
} 


[Peca]

i brojeve konvertovati u integer:

PHP kôd:

$_GET['id'] = intval ( $_GET['id'] );