Glasanje: prevencija "SQL injection"
Недавно сам видео овај текст: http://bobby-tables.com/
Па ме интересује како радни народ спречава сигурносни пропуст познат по имену "SQL injection" илити у преводу убризгавање SQLa. Да ли радите "санитизацију" улаза, или користите параметаризоване упите или не радите ништа по том питању... |
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 ... |
^ 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 |
^ 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
|
Filter input - escape output. Sve dok se drzis te mantre sve je ok ;)
|
Kad se koristi Rails, logično je (iz primera na bobby-tables.com):
Kôd:
Person.find :all, :conditions => ['id = ? or name = ?', id, name] Kôd:
dataset.filter(:name => 'abc') |
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...
|
За сада ми се допадају Робијев и Јабланов одговор. Него, баш ме занима шта мисле Дејан Топаловић, Дегојс и још пар људи који се не јављају.
|
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. |
ima i mysqli prepared statements, kad smo vec kod toga, ne mora pdo..
|
jeste, ali je mysqli vezan samo za mysql, nesto nije portabilan? A sem toga postoje ljudi koji koriste i druge baze...
|
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 ... |
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 ;)
|
Citat:
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 ... :) |
@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? |
^ hm, zasto bi (t.j. kako) view bio mera zastite?
P.S. da, i mene interesuje ovo za php |
Citat:
Od tada je PHP banovan kod nas. :D |
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...
|
^ de "Milane" vidi nabrzaka sta mi pise u horoskopu i baci grah nabrzaka, vidi sa 99.99999% sigurnoscu sta ce mi donijeti bliza buducnost ... ;)
|
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... |
Citat:
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. |
Ovo gore navedeno vazi za svaki OS, programski jezik ili aplikaciju odnosno ne znam niti jedan na koji to ne moze da se primeni.
|
@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. |
Citat:
|
Citat:
|
Citat:
Š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:
|
Citat:
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:
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 14:58. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.