DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 17. 03. 2007.   #1
[nq]
web dude
Grand Master
 
Datum učlanjenja: 09.06.2005
Poruke: 912
Hvala: 46
24 "Hvala" u 21 poruka
[nq] is on a distinguished road
Default 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
[nq] je offline   Odgovorite uz citat
Staro 17. 03. 2007.   #2
Dragi Tata
dinosaurus
Master
 
Avatar Dragi Tata
 
Datum učlanjenja: 29.12.2005
Lokacija: Nova Engleska
Poruke: 636
Hvala: 79
257 "Hvala" u 66 poruka
Dragi Tata će postati "faca" uskoroDragi Tata će postati "faca" uskoroDragi Tata će postati "faca" uskoro
Default

Citat:
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
Dragi Tata je offline   Odgovorite uz citat
Staro 17. 03. 2007.   #3
LiquidBrain
Milan Cvejic
Wrote a book
 
Avatar LiquidBrain
 
Datum učlanjenja: 05.09.2006
Lokacija: Beograd
Poruke: 1.241
Hvala: 32
73 "Hvala" u 56 poruka
LiquidBrain će postati "faca" uskoro
Pošaljite poruku preko Yahoo za LiquidBrain
Default

Veruj mi ima potrebe da sve proveravash.

Ajde saljem ti PM u toku dana sa detaljnim objashnjenjem.
__________________
http://weevify.com
LiquidBrain je offline   Odgovorite uz citat
Staro 17. 03. 2007.   #4
phatsa
član
Certified
 
Datum učlanjenja: 11.07.2006
Poruke: 84
Hvala: 1
2 "Hvala" u 2 poruka
phatsa is on a distinguished road
Default

^ 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.
phatsa je offline   Odgovorite uz citat
Staro 17. 03. 2007.   #5
LiquidBrain
Milan Cvejic
Wrote a book
 
Avatar LiquidBrain
 
Datum učlanjenja: 05.09.2006
Lokacija: Beograd
Poruke: 1.241
Hvala: 32
73 "Hvala" u 56 poruka
LiquidBrain će postati "faca" uskoro
Pošaljite poruku preko Yahoo za LiquidBrain
Post 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:
    +-----------+----------------------+-----------------+
    |     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
Kôd:
http://www.example.com/index.php?uname=admin&passwd=123456
nama ce se izvr****i sledeci query:
Kôd:
  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.
Kôd:
http://www.example.com/index.php?uname='admin&passwd=123456
I u ovo slucaju dobijamo greshku jer query izgleda ovako:
Kôd:
  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
Kôd:
     ' OR '1'='1
i isto to za passwd parametar. Dakle
dobijamo sledeci query.
Kôd:
   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.
__________________
http://weevify.com
LiquidBrain je offline   Odgovorite uz citat
Staro 17. 03. 2007.   #6
misk0
majstor
Wrote a book
 
Avatar misk0
 
Datum učlanjenja: 30.01.2006
Lokacija: Lugano - Switzerland
Poruke: 1.251
Hvala: 219
106 "Hvala" u 67 poruka
misk0 će postati "faca" uskoromisk0 će postati "faca" uskoro
Pošaljite ICQ poruku za misk0 Pošaljite poruku preko Skype™ za misk0
Default

Citat:
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
misk0 je offline   Odgovorite uz citat
Staro 17. 03. 2007.   #7
Ivan
Psychedelictrance freak
Wrote a book
 
Avatar Ivan
 
Datum učlanjenja: 04.06.2006
Lokacija: Srbija, Beograd
Poruke: 1.008
Hvala: 325
940 "Hvala" u 34 poruka
Ivan će postati "faca" uskoroIvan će postati "faca" uskoroIvan će postati "faca" uskoroIvan će postati "faca" uskoroIvan će postati "faca" uskoroIvan će postati "faca" uskoroIvan će postati "faca" uskoroIvan će postati "faca" uskoro
Pošaljite poruku preko Skype™ za Ivan
Default

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, ...
Ivan je offline   Odgovorite uz citat
Staro 17. 03. 2007.   #8
cvele
Banned
Knowledge base
 
Avatar cvele
 
Datum učlanjenja: 01.07.2005
Poruke: 1.598
Hvala: 206
140 "Hvala" u 89 poruka
cvele ima spektakularnu aurucvele ima spektakularnu auru
Default

provera tipa varijable, mod_secure, mysqli bind.
cvele je offline   Odgovorite uz citat
Staro 18. 03. 2007.   #9
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
1.956 "Hvala" u 579 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

Citat:
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_likeaddcslashes($str'%_') : $str );

__________________
Leadership is the art of getting people to want to do what you know must be done.

Poslednja izmena od ivanhoe : 18. 03. 2007. u 01:34.
ivanhoe je offline   Odgovorite uz citat
Staro 18. 03. 2007.   #10
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
267 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

i brojeve konvertovati u integer:
PHP kôd:
$_GET['id'] = intval $_GET['id'] ); 
__________________
Vesti | MyCity | Igrice | Zaštita od virusa
Peca je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Kod kojem ne treba dokumentacija... mangia Opušteno 10 12. 10. 2009. 22:27
Glasanje: prevencija "SQL injection" Dragi Tata SQL baze podataka - Sponzor: Baze-Podataka.net 26 20. 09. 2009. 01:02
Treba mi secondary DNS misk0 Web aplikacije, web servisi i software 1 18. 06. 2009. 21:47
Treba nam Robocop :) bluesman Opušteno 3 17. 12. 2007. 19:21
PHP email injection MorenoArdohain Programiranje 0 07. 01. 2006. 23:32


Vreme je GMT +2. Trenutno vreme je 04:03.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2017, 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.