preventiva pred napadi na php+mysql strani

Lotil sem se izdelave php + mysql strani. Ob prebiranju tutorialov sem naletel tudi na možnosti napadov na te strani (sql injection). Načinov zaščite je veliko, ker je načinov vdora prav tako veliko. Osnovni princip je nadzor vpisov in prenos vpisov v sql querye. Zanima me kako zaščito uporabljate vi in ali je zaradi možnosti napada bolje uporabiti kako drugo platformo?

sebavet> Zanima me kako zaščito uporabljate vi

Danes je pričakovano, da uporabljaš ogrodje (framework), ki skrbi za te reči (komponenti, ki dela z bazo in preprečuje "SQL injection" napade se običajno reče ORM - object-relational mapper).

Nekaj več o ORM (in PHP): http://stackoverflow.com/questions/1086...

ORM je komponenta, ki skrbi za vso interakcijo z bazo, zato da tebi ni treba programirati vsega od začetka.

Lepota ORM sistema (in ostalih knjiznic, frameworkov ipd.) je ravno to, da svojih aplikacij potrebno spremljati ves čas (24 ur dnevno, 7 dni na teden, 365 dni na leto).

Če uporabljaš dober ORM oz. framework veš, da so verjetno boljši programerji od tebe sprogramirali in temeljito stestirali vmesnik za delo z bazo. V kolikor si v skrbeh za varnost, preprosto redno spremljaš posodobitve za tvoj framework.

Mislim, da ste narobe razumeli mojo objavo. Nič ne de :)

"V kolikor" sem zapisal zato, ker avtor več kot očitno daje poudarek varnosti, kar je pohvalno.
Veliko spletni mojstrov danes temu ne posveča veliko pozornosti, če sploh kaj.

Če bi sicer vedel, da bo spakedranka "V kolikor" izzvala prekomerno rabo ločil, bi seveda uporabil besedo "Če".
Upam, da vas nisem preveč vznemiril :)

Kar se tiče varnosti in gostovanja - ne razumem kako bo razprava v tej smeri pomagala avtorju.
Me pa vseeno veseli, da se zavedate, da tudi slovenska gostovanja sledijo svetovnim trendom :)

Ne se toliko razburjati prosim!

Če ste med gostitelji, ki imajo najmanj težav z varnostjo, to še ne pomeni, da na drugi strani ni takih, pri katerih so kompromitacije na dnevnem redu!

Izhahajoč iz predpostavke, da imate vsi gostitelji približno enako 'pametne' uporabnike storitev, se lahko pojasni velika razlika v številu kompromitacij le tako, da eni gostitelji naredite bistveno več za varnost, kot drugi - ne glede na to, kaj na drugem koncu počno uporabniki.

Ravno tako ne moreš prevaliti krivdo na uporabnike, če pride do serijske kompromitacije, ko npr. v enem dnevu kompromitirajo 300+ spletišč na istem strežniku - tudi to se namreč dogaja in kaže na določene težave na strani ponudnika in ne uporabnikov - upam, da se strinjaš?

Ravno tako ne moreš prevaliti krivdo na uporabnike, če pride do serijske kompromitacije, ko npr. v enem dnevu kompromitirajo 300+ spletišč na istem strežniku - tudi to se namreč dogaja in kaže na določene težave na strani ponudnika in ne uporabnikov - upam, da se strinjaš?

Deloma se strinjam s tabo.
Vsi napadeni uporabniki so uporabljali neposodobljene priključke ali neposodobljene cms sisteme. Če bi bila krivda na strani gostitelja bi bili napadeni vsi uporabniki. Redno posodobljeni cms sistemi so ob teh napadih ostali nedotaknjeni.

Kar hočem povedati je to, da ob rednem posodabljanju in upoštevanju predlogov s strani ponudnika gostovanja, ki jih v zadnjem obdobju ni bilo malo, (le upošteva jih ne nihče) je skoraj win-win situacija.

@Estreznik: 'Izvorni greh' je takointako v večini primerov na strani uporabnikov oz. programerjih / vzdrževalcih njihovih spletišč / virtualk. O tem ni nobenega dvoma.

Toda ponudniki imate kljub vsemu v svojih rokah možnost nuditi neko dodano vrednost k samemu gostovanju in dodatno zavarovati spletišča, ki pri vas gostujejo proti najbolj pogostim neumnostim, ki jih uporabniki počno.

Da je temu tako, dokazuje statistika. Če je velik ponudnik gostovanja imel pred uvedbo dodatnih varnostnih ukrepov po 50 kompromitacij na mesec, se je to število po uvedbi zmanjšalo na vsega eno na mesec! Torej se da, mar ne?

Ali se tega lotite z reverse proxi-jem, web application firewall-om, DPI, IPS ali čisto tretjim pripomočkom oz. kombinacijo njih, je pri tem popolnoma vseeno - govorim o rezultatu.

Nekateri od ponudnikov ste v tovrstna orodja investirali kar lepe denarje in ne razumem, zakaj iz tega delate nekakšno skrivnost in se pretvarjate, da nimate nobene sekundarne zaščite in VSE zavisi izključno od posluha uporabnikov za vaša opozorila za posodabljanje.

Seveda je reklamiranje sekundarne varnost dvorezen meč in se lahko še kako maščuje, če se preveč zanašamo nanjo in ta zaščita enkrat odpove. Zato nikakor ni za zanemariti rednega posodabljanja samih spletišč.
Vendar tudi tu lahko ponudniki zadeve avtomatizirate - skenirate gostujoča spletišča in preverjate posodobljenost CMS-ov. Če stranka potem kljub opozorilom zadeve ne uredi, pa lahko tudi posežete po najbolj drastičnem ukrepu - začasni blokadi dostopa do spletišča.

Vem, da takšne postopke nekateri že uporabljate in prav je, da jih. Če bi jih uporabljali vsi, se tudi nebi rabili bati, da vam bo stranka pobegnila, ko bi ji začasno ukinili dostop do spletišča. Tako pa morate tehtati, kaj vam bo prineslo večjo korist.

Če je zone-h.org kaj za verjeti, sta letos naše ponudnike udarili dve večji kompromitaciji - prva januarja s 103 registriranimi prizadetimi spletišči in druga prejšnji mesec s celo 306 prizadetimi spletišči (številke obsegajo zgolj spletišča s .si domenami). V obeh primerih je bila v igri ena sama IP adresa na ponudnikovi strani. Ker noben ponudnik takšnih kompromitacij ne obeša na veliki zvon, lahko samo ugibamo, kaj je bil vzrok, vendar je vsekakor večja verjetnost, da je bila krivda na ponudnikovi strani, kot pa na uporabniški.