DevProTalk - Glasanje: prevencija "SQL injection"

DevProTalk (http://www.devprotalk.com/index.php)

- SQL baze podataka - Sponzor: Baze-Podataka.net (http://www.devprotalk.com/forumdisplay.php?f=10)

- - Glasanje: prevencija "SQL injection" (http://www.devprotalk.com/showthread.php?t=7875)

Dragi Tata

16. 09. 2009. 16:18

Glasanje: prevencija "SQL injection"

Недавно сам видео овај текст: http://bobby-tables.com/

Па ме интересује како радни народ спречава сигурносни пропуст познат по имену "SQL injection" илити у преводу убризгавање SQLa. Да ли радите "санитизацију" улаза, или користите параметаризоване упите или не радите ништа по том питању...

Blood

16. 09. 2009. 16:22

pa..osim escape-ovanja ulaza, ja imam i black listu reci (mysql f-ja) koje se filtriraju, kao zastita i od blind SQL Injection.

U sustini zabranjujem INSERT, DELETE, SELECT, SLEEP ...

robi-bobi

16. 09. 2009. 16:29

^ taj filtar bi trebao biti pametan kako ne bi filtrirao tekst:
"your select button is not working"

ranije sam koristio mysql_real_escape_string
sad PDO

Blood

16. 09. 2009. 16:52

^ u pravu si, pogresno sam se izrazio malopre. Predjasnji post se odnosio na podatke gde sam korisnik ne bi trebao da ima kontakta sa samim sql upitom

dinke

16. 09. 2009. 17:42

Filter input - escape output. Sve dok se drzis te mantre sve je ok ;)

jablan

16. 09. 2009. 19:36

Kad se koristi Rails, logično je (iz primera na bobby-tables.com):

Kôd:

Person.find :all, :conditions => ['id = ? or name = ?', id, name]

Skoro sam naišao na Sequel - još jedan zgodan DB toolkit za Ruby (kad nema potrebe za celom ActiveRecord mašinerijom). Tamo se filterovanje datasetova radi ovako:

Kôd:

  dataset.filter(:name => 'abc')

  dataset.filter('name = ?', 'abc')



  dataset.filter{|o| o.value > 100}

  dataset.exclude{|o| o.value <= 100}



  dataset.filter(:value => 50..100)

  dataset.where{|o| (o.value >= 50) & (o.value <= 100)}



  dataset.where('value IN ?', [50,75,100])

  dataset.where(:value=>[50,75,100])



  dataset.filter(:name => 'abc').first

  dataset[:name => 'abc'] # same as above



  # Filter using a subquery

  dataset.filter{|o| o.price > dataset.select(o.avg(price) + 100)}

http://sequel.rubyforge.org/rdoc/fil...ring_rdoc.html

ivanhoe

16. 09. 2009. 20:27

ako koristis odgovarajuce escape-ovani input ili prepared statements to bi trebalo da je to... za XSS treba jos escapeovati i output (na odgovarajuci nacin, zavisno da li ide u html ili u atribute ili eventualno url) i onda moozes relativno mirno da spavas...

Dragi Tata

17. 09. 2009. 16:19

За сада ми се допадају Робијев и Јабланов одговор. Него, баш ме занима шта мисле Дејан Топаловић, Дегојс и још пар људи који се не јављају.

LiquidBrain

17. 09. 2009. 17:40

Definitivno PDO i prepared statements... Prepared statements su dobro resenje i zbog performansi, pogotovu ako se isti upit pojavljuje par puta.

Elem, sto se tice PDO-a mora dobro da se pazi, jer je on samo jedna linija odbrane... Definitivno preporucujem stripovanje specijalnih karaktera iz svih user input-a, ili enkodovanje istih.

ivanhoe

17. 09. 2009. 19:34

ima i mysqli prepared statements, kad smo vec kod toga, ne mora pdo..

LiquidBrain

17. 09. 2009. 21:53

jeste, ali je mysqli vezan samo za mysql, nesto nije portabilan? A sem toga postoje ljudi koji koriste i druge baze...

Ivan	18. 09. 2009. 01:11

Uglavnom, kao sto je i navedeno do sada bitno je filtrirati ulazne vrednosti tj odstraniti ono sto ne treba da se pojavi u upitu.

Vecina stvari se zavrsi cast-ovanjem varijabli i zabranom kljucnih reci (SELECT, INSERT, SLEEP, ...) i/ili karaktera (', %, ;,...).

Dosta je bitno sta se zapravo od logike aplikacije ocekuje a sta ne, nekad security moze da smanji upotrebljivost aplikacije pa se samim tim mora ici drugim putem ...

degojs

18. 09. 2009. 01:48

Parametri.. i rešena stvar, nema brige. A ako iz nekog razloga ne može sa parametrima, onda ne može, šta da se radi ;)

Dejan Topalovic

18. 09. 2009. 10:47

Citat:

Originalno napisao Dragi Tata (Napišite 73326)

Evo javljam se :) Ejs ko da sam ja neki autoritet na podrucju baza podataka, pa da ti treba i moje misljenje hehehe

Iskreno, sa MySQL-om ne radim aktivno vec nekoliko godina :( , jer zbog prirode posla sam prinudjen iskljucivo na Oracle bazu, tako da mogu samo za nju nesto reci...

Mi imamo kompleksan sistem, u kojem se koriste razne intranet i internet aplikacije, pocevsi od desktop aplikacija uradjenih u Delphiju i Visual Basicu, preko batch operacija (scheduler + sqlplus i sl.), pa sve do viseslojnih Java aplikacija (browser based: proxy, connection manager, application server).
Vjeruj mi da je tesko postici neko homogeno rjesenje, kojim bi se 100% sprijecio neki napad ili provala u sistem.

Ukratko, direktno u bazi koristimo parametrizovane procedure, redovno kontrolisem access logove (plus auditing svih SYSDBA komandi) i instaliram sigurnosne zakrpe (Critical Patch Update).

Java programeri koriste "sanitization" ulaznih podataka (dvojica od njih trenutno cak zavrsavaju master studij zasnovan na IT security podrucju) i nismo imali jos nijedan slucaj upada u sistem preko neke Java aplikacije.

Imali smo do sada 2 manja upada u sistem, tj. na web server, a za sve je bilo krivo nekoliko bugova u PHP-u, pomocu kojih je bio omogucen remote exploit. Nismo imali nikakve vece stete, osim par dana prekovremenog rada i izgubljenih zivaca. Zbog ta 2 slucaja je donesena odluka da se PHP u potpunosti izbaci iz sistema i da se svi buduci online projekti zasnivaju na Javi.

Eto, ne znam sta bih vise dodao na ovu temu ... :)

ivanhoe

18. 09. 2009. 11:36

@dejan: Jel moze samo malo detaljnije ovo oko bugova u php-u, jel mislis na bagove u php skriptama, ili bas propuste u samom php-u?

@svi: Da li koristite view-ove i stored procedure kao meru zastite?

robi-bobi

18. 09. 2009. 12:29

^ hm, zasto bi (t.j. kako) view bio mera zastite?
P.S. da, i mene interesuje ovo za php

Dejan Topalovic

18. 09. 2009. 14:12

Citat:

Originalno napisao ivanhoe (Napišite 73350)

@dejan: Jel moze samo malo detaljnije ovo oko bugova u php-u, jel mislis na bagove u php skriptama, ili bas propuste u samom php-u?

Nakon svakog upada, angazovali smo eksternu security firmu (al' su nas oderali, satnica im je bila 200 EUR), koja je pregledala sve application servere i nakon visesatne/visednevne lobotomije ustanovila da se radilo o propustima u samom PHP-u, a u drugom slucaju o PHP-u i ActiveDirectory-u.

Od tada je PHP banovan kod nas. :D

mangia

18. 09. 2009. 15:43

Ne bih da budem prepotentan ali za 0 Eura ću vam reći (sa sigurnošću od 99.998%) da je u pitanju propust programera a ne PHP-a...

Dejan Topalovic

18. 09. 2009. 15:56

^ de "Milane" vidi nabrzaka sta mi pise u horoskopu i baci grah nabrzaka, vidi sa 99.99999% sigurnoscu sta ce mi donijeti bliza buducnost ... ;)

LiquidBrain

18. 09. 2009. 16:08

PHP nije jedini koji ima mana i bugova... Ako cemo tako ni Java nije 100% sigurna... Svakako morash da terash za javu neki aplikativni server... Pogledaj samo koliko propusta postoji za Tomcat, Glassfish, JBOSS...

Poenta je da drzite sistem up to date...

holodoc

18. 09. 2009. 17:04

Citat:

Originalno napisao LiquidBrain (Napišite 73357)

Nije ni PHP baš toliko nevin s obzirom da ima jako interesantnu istoriju bagovitih buildova posebno u periodu dok je "četvorka" žarila i palila web development scenom. Često se dešavalo da upravo novi build unese nove propuste koji u prethodnoj verziji nisu postojali pa je tako neko osnovno pravilo koje se preporučuje u slučaju PHPa da se pre updatea na novu verziju ostavi da ona "sazri". Drugim rečima tek kada bug trackeri za dotičnu verziju počnu da skapaju od gladi i naslovi tema na mailing listama vezanim za novu verziju PHPa ne prestanu da počinju sa "[Help]", "[Bug]" itd. preporučuje se prelazak na novu verziju. Po meni jedina stvar koja je gora od korišćenja stare verzije softvera za koju su poznati svi ozbiljni bugovi je korišćenje nove za koju se ne zna kakve sve boljke može da sadrži pod haubom.

Vezano za tehnike prevencije SQL injekcije moj stav je da kada god mogu koristim PDO. U PHPu, koji najčešće koristim u poslednje vreme, nažalost često dolazim u situaciju da PDO nije dostupan ili je jednostavno u pitanju postojeći kod gde mora da se koriste ugrađene PHP funkcije za prevenciju injekcije. U takvim slučajevima ne preostaje ništa drugo nego otvaranje šestoro očiju jer escape-ovanje ugrađenim PHP funkcijama može ponekad da bude veoma "mutno". Poslednje negativno iskustvo koje sam imao sa njima je bilo pre par meseci kada sam na analizu dobio gotov sistem koji je uporno propuštao injektovane podatke u bazu koji su kasnije mogli da se bez problema iskoriste za XSS napade. Ispostavilo se da je originalni autor veoma uspešno rešio problem prevencije SQL injekcije korišćenjem mysql_real_escape_string funkcije nad početnim podacima (klasično textarea polje) međutim pretpostavio je da jednom escapeovani maliciozni podaci u bazi više ne predstavljaju problem tako da kada se "povuku" iz baze više nisu opasni. Drugim rečima, u toku upisa podataka nakon njihove izmene (edit) nije korišćen mysql_real_escape_string jer je autor pogrešno pretpostavio da pomenuta funkcija u stvari "čisti" maliciozni kod koji se upisuje u bazu.

Što se tiče korisnih alatki za testiranje web sajtova na najznačajnije propuste zaista od srca preporučujem Acunetix Web Vulnerability Scanner. Tačno je da je izuzetno skupa a i da se veoma teško može naći u "narodskoj" verziji ali iako izgleda kao još jedna u nizu aplikacija koja "ubode" tu i tamo pokoji propust u web aplikacijama ova alatka se kod mene pokazala kao odličan izvor jako korisnih informacijama o propustima na sajtu. Dobra stvar je što za svaki propust koji se pronađe u web aplikaciji postoje detaljni opisi i linkovi ka dodatnim informacijama o konkretnom propustu što znači i da je ekstra pogodna za edukativne svrhe.

bOkIcA

18. 09. 2009. 17:11

Ovo gore navedeno vazi za svaki OS, programski jezik ili aplikaciju odnosno ne znam niti jedan na koji to ne moze da se primeni.

mb_sa

18. 09. 2009. 19:39

@holodoc

Jesu li rješili problem sa SEO (clean) URL-ovima? Koristio sam poodavno Acunetix Web Vulnerability Scanner i koliko se sjećam nije mogao da testira sajtove koji su imali SEO urls.

holodoc

18. 09. 2009. 20:53

Citat:

Originalno napisao mb_sa (Napišite 73368)

@holodoc

Jesu li rješili problem sa SEO (clean) URL-ovima? Koristio sam poodavno Acunetix Web Vulnerability Scanner i koliko se sjećam nije mogao da testira sajtove koji su imali SEO urls.

Verzije koje sam koristio u poslednje dve-tri godine nisu imale apsolutno nikakvih problema sa bilo kojim oblikom SEO optimizovanih linkova.

ivanhoe

18. 09. 2009. 22:10

Citat:

Originalno napisao robi-bobi (Napišite 73351)

^ hm, zasto bi (t.j. kako) view bio mera zastite?

u kombinaciji sa stored procedurama kao vid kontrole koje podatke mozes da dohvatas, a koje ne..

mangia

19. 09. 2009. 17:32

Citat:

Originalno napisao Dejan Topalovic (Napišite 73356)

^ de "Milane" vidi nabrzaka sta mi pise u horoskopu i baci grah nabrzaka, vidi sa 99.99999% sigurnoscu sta ce mi donijeti bliza buducnost ... ;)

Ne moze... Ne slusas "White Snake"

Šalu na stranu ali pokušavam reći da je PHP jedan od najčešćih i nalakših jezika za početnike od kojih većina prve korake pravi zahvaljujući sumnjivim tutorialima i copy - paste metodom bez imalo razmišljanja o bezbijednosti...

Ako su ti profesionalci već rekli da je do PHP-a niste morali prepisivati aplikaciju drugim jezikom. Mogli ste uraditi update ili prepravku problematičnog dijela koda...

Citat:

sta ce mi donijeti bliza buducnost ... ;)

Vidim neko pivo na moj račun... Samo da dodješ u BL... :)

Dejan Topalovic

20. 09. 2009. 00:02

Citat:

Originalno napisao mangia (Napišite 73379)

Ako su ti profesionalci već rekli da je do PHP-a niste morali prepisivati aplikaciju drugim jezikom. Mogli ste uraditi update ili prepravku problematičnog dijela koda...

Pa prvi put je šef progledao PHP-u kroz prste i ta aplikacija se nastavila razvijati u PHP-u. Međutim, nakon drugog slučaja je šef bez puno razmišljanja otpisao PHP za sve buduće projekte...
Naravno da su u mnogim slučajevima krivi i sami programeri, ali ove propuste u PHP-u je potvrdila eksterna security firma, tako da se skine krivica sa programera...

Citat:

Vidim neko pivo na moj račun... Samo da dodješ u BL... :)

Kad je beg bio cicija? :D
Nego, ćevapi sa pivom bi bili još bolji, a?

A sad ću ja da vam napišem nešto o sigurnosti baza podataka...

Kao prvo, najveću zaslugu za sigurnost neke baze podataka, u mom slučaju Oracle baze, imaju na prvom mjestu network administratori (tj. Cisco stručnjaci), koji su na prvoj liniji odbrane. Ako oni dobro podese access filtere, firewalle, proxye i druge "networkalije", onda je to veliko olakšanje drugoj (system administratori) i trećoj (database administratori) liniji odbrane.

Znači, database administrator može i da nešto previdi, zaboravi, iz neiskustva loše konfiguriše bazu i td., ali će se taj previd teže uočiti ukoliko network i system administratori svojim odličnim radom onemoguće neovlašten pristup bazi.

Oracle RDBMS je pun rupa i bugova, maltene bušan ko sir (karirikam), ali je te propuste teško iskoristiti, jer se moraju najprije proći prva i druga linija zaštite. Kad bi network i system administratori zakazali, te omogućili neovlašten pristup Oracle bazi, 50% Oracle administratora bi dobili otkaz...

Ne kažem ja da je tih 50% Oracle administratora nesposobno, jer oni nisu krivi za neki bug u Oracle bazi, zbog kojeg neki napadač ima neovlašten pristup bazi i mogućnost da nanese štetu...

I za kraj jedan savjet svim administratorima baza podataka - budite prijatelji sa svojim developerima, network i system administratorima, jer od njih zavisi i vaš posao.

Vreme je GMT +2. Trenutno vreme je 20:39.

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.