Názory k článku (Ne)bezpečí databázových aplikací v PHP

Prominte, ale tohle je dost stara polevka, nemylim-li se. Technika SQL command inject je klasika cracku databazovych aplikaci a s chuti pouzivana, viz napr. v posledni dobe uverejneny clanek http://ug.cz/969.

BTW, ja osobne bych kontroloval uzivatelsky vstup regularnim vyrazem :o)))

Prave zmineny clanek na ug a nezmineny clanek na
nejmenovanem serveru je dukazem toho, ze je porad
mnoho lidi, kterym je treba tuto latku opakovat.
Koneckoncu i kontrola regularnim vyrazem namisto
prosteho porovnavani svedci o neprilis velkem smyslu pro efektivitu a namyslenosti programatora, ktery se
domniva, ze regularni vyrazy pise se stejnou jistotou
jako porovnani dvou promennych.

Zdravim vsechny namyslene programatory :o) , tedy pokud slovo 'namysleny' je podobneho vyznamu, jako 'natrenovany' ci 'nadupany" ...

Obavam se, ze pro skolni pripad 4 moznych variant je sice porovnani s vyctem pouzitelne, ale pro jenom trochu slozitejsi pripad (napr. korektni vstup muze byt AAA-ZZZ) se dostavame, mily nenamysleny kritiku, ke 26^3 = 17576 polozkam seznamu. Prijemne efektivni programovani!

A pokud jde o opakovani obecnych pravd na teto urovni, pak jednu, s dovolenim, pridam:

JE VELMI VHODNE OPATRIT ROOT ACCOUNT HESLEM ...

nepatri tam ta tecka

http://www.ug.cz/969

Jak bylo v clanku zmineno o sifrovani hesel, blahovy je ten, ktery je uklada v plaintextu. Pro uzivatele, ktere neco takoveho nenapadne je toto pomerne velkym bezpecnostnim rizikem, protoze spousta lidi si dava stejna hesla a kdyz ho nekam ulozim v plaintextu, tak pak jako bych ho vyvesil primo na webu (temer). Kazdopadne ho muze zneuzit administrator DB!

Administrator ho muze zneuzit v kazdem pripade, i kdyz je sifrovane. Jen je to o malinko tezsi, nez kdyz je plain. Nebezpecim je spis unik plain hesel pri neopravnenem pristupu do databaze. Ale i kdyz jsou hesla sifrovana, tak si moc nepomuzete, protoze spousta uzivatelu ma takova, ktera jdou vylouskat slovnikovym utokem :-|

A ze jsem tak smely, jak nebohy uzivatel, ktery akorat chce vyuzivat nejakou webovou aplikaci zajisti, aby system hesla ukladal kryptovane? ;-)
Podle me ma akorat prave tu moznost, pouzivat ruzna hesla. Jinak bych si dovolil zminit, ze pekna serie o nabouravani PHP skriptu vysla jiz na intervalu.
Jinak souhlasim s autorem clanku, ze toto nebezpeci je neustale treba pripominat, protoze je az neuveritelne, jak casto se prave v kontrole dat od uzivatele chybuje.

Zakladny a jednoduchy krok ku kryptovaniu hesiel je pouzivat MySQL-funkciu PASSWORD(). Pri vytvarani noveho uzivatela sa heslo ulozi v kodovanej podobe a neskor uz nie je potrebne toto heslo vobec citat.

INSERT INTO user SET login='uzivatel', password=PASSWORD('heslo');

Pri prihlaseni sa potom porovnava ulozene zakodovane heslo so zadanym heslom, ktore prejde funkciou PASSWORD:

SELECT login FROM user WHERE login='zadany_uzivatel' AND password=PASSWORD('zadane_heslo');

ak je heslo spravne, tak to vrati jeden riadok. Vyhoda tohoto systemu je, ze ani administrator nemoze odhalit (v realnom case dostupnou vypoctovou kapacitou) ulozene hesla. V pripade, ze uzivatel zabudne svoje heslo, je vsak jednoduche jeho heslo zmenit na nahodne vygenerovane, poslat mu ho mailom a poziadat ho, nech si ho okamzite zmeni:

UPDATE login SET password=PASSWORD('nove_heslo') WHERE login='zadany_uzivatel' AND password=PASSWORD('nahodne_vygenerovane_a_zadane_heslo');

ech. Blbost! Jak chcete aministrátorovi zabránit aby si po každém zavolání

SELECT login FROM user WHERE login='zadany_uzivatel' AND password=PASSWORD('zadane_heslo');

v případě úspěchu uložil dvojici 'zadany_uzivatel' a 'zadane_heslo' přímou úpravou PHP aplikace. Nijak. Tož a tak je to se vším. Když ještě uvážím, že administrátor může být v určitou chvíli 'administrator' tak jsou hesla uložená v db v pr.. tak jako tak bez ohledu na to jestli jsou v plain, nebo ne. Jediné co se změní je míra průniku. Je to stejné jako udělat patch na login, nebo odchytávat stisknuté klávesy. Zkrátka jediné správné a obecně platná pravidla zní: 1/ Pro různé služby !vždy! používat různá hesla. 2/ Proti administrátorovi neexistuje neprůstřelná ochrana.

Tak tak,
stejne jako Buh je i Administrator, ve vetsine soucasnych systemu vsemocny. Proto se zavadi Auditor, ktery vladne nad vsemi Administratory, ale nema zadna prava vuci sluzebnictvu (alias BFU).
seth

Mluvilo se o administratorovi databaze. Ja treba v praci provozuji webowou aplikaci, pouzivam databazi kterou ale administruje nekdo jiny. Ani nevim kolik ruznych lidi vlastne k te databazi ma pristup. Protoze ale hesla jsou sifrovana, tak mi je to v celku jedno. Takze smysl to ma. To same plati i na ruznych webhostincich a podobne.

Navic u me se sifrovane odesli uz heslo z prohlizece, navic pokazde v jine podobe a v databazi je tak uz vlastne dvojnasobne zasifrovane. Nabourat takovy mechanizmus uz da vice prace, musi se tomu rozumet a musi byt pristup ke zdrojakum. U PHP je to problem i kdyz by take bylo mozno napr. sledovat jejich CRC32. Je-li aplikace napsana napr. v Pythonu, tak tam staci mit jen kompilovane objekty a ty se modifikuji uz velmi tezko, prakticky to je nemozne.

a hele, dalsi lame admin, PASSWORD se neodporucuje pouzivat - totiz v pripade mySQL 3 a 4 to sifruje na jinou delku - je to funkce pro vnitrni potrebu mySQL. Misto toho je lepsi mit MD5, SH1 a sifrovani provadet na strane PHP - to vyplyva z toho ze data mohou putovat po spojeni s mySQL taky v plain textu.

vice na http://www.mysql.com/doc/en/Password_hashing.html

v odstavci
4.3.12 Implications of Password Hashing Changes for Application Programs

Tak nejak mi prijde volani md5(passwd) nebo sha1(passwd) vicemene nesmyslne ... :-/

Myslim, ze to je srovnatelne s volanim crypt(passwd, 'aa') ...

Kdyz se podivate na zdrojaky md5-crypt treba v glibc, zjistite, ze to neni ubohe md5(passwd), ale je to slozitejsi (a osolena) transformace vyuzivajici jako zaklad md5. A pokud vas zajimaji duvody, google je kamarad.

Nechci se vyjadrovat k SQL injection, ale
mne spis zarazil napad ukladat jazyk do specialniho sloupce .... neni nahodou jednodussi a elegantnejsi mit id jazyka jako klic v tabulce textu???

SELECT blabla
FROM blabla
WHERE textid = :id
language = :language

No nazdar, seth.

Moje řeč. Ať žije škálovatelnost :-)

Presne tak. Kod, resp. datovy model co je komentovany v clanku z ruky alespon trochu zkuseneho navrhare nikdy nevzejde. Krome problemu s implementaci - komplikace selektu, sql injection, ma i jine nedostatky plynouce ze samotne struktury tabulky.

No pokud bude potreba v prikladu uvadenem v clanku pridat dalsi jazyk tak potes panbuh. :-) Jedine co pro to hovori je mozna rychlost, protoze se tam nemusi delat joiny, ale vsechno je v jedne tabulce. Ale kvuli tehle vyhode bych se nevzdaval moznosti pridat dalsi jazyk jen insertem do tabulky jazyku.

Dost prapodivna debata. Sam jsem tedka podobny problem resil. Oznacovat texty ciselnym ID je mozne na malem webu jinak se v tom casem stratite. Vetsina aplikaci pouziva alespon kretke retezce.

Ja jsem ale radsi sahnul k predkompilovanym jazykovym mutacim. Mam pro kazdy jazyk samostatny soubor prekladu, v trochu hard kor podobe (jako $pole['text skriptu']='text prekladu') tento text staci jen natahnout, spustit pres eval() a mate nadherne naplnene pole. Pak jen spustite skriptik pro preklad stranek (s trochou otimalizace, bude prekladat jen co bylo skutecne zmeneno) a mate dve, tri a vice jazykovych mutaci.

V pripade webgamesy, kde je nekolik klikset kliknuti do minuty vam bude procesor a db server vdecny za to ze ho zbytecne nezatezujete.

je sice pekne ze upozornujete na bezpecnost, ale treba rozlisovat medzi step-by-step tutorialmy a perfektne zabezpecenym kodom. clovek co nikdy v php nepisal nepotrebuje vediet ze sa to takto nepise - je rad ze mu to vobec funguje :o) zda sa mi ze tento clanok je len ukazanim ze niekto to vie lepsie - a nevie to lepsie. nechapem preco nie je pouzita funkcia mysql _password_ alebo este lepsie _md5_ a tymto aj zdravim experta na bezpecnost. dufam ze dospejes a budes si cenit aj svojich protivnikov - co by sme boli ak by nam nikto neodporoval.

>dufam ze dospejes a budes si cenit aj
>svojich protivnikov

No nevim ale myslim ze nazev clanku nebyl jak ukladat bezpecne hesla do DB ale trochu jiny.
BTW: Ty mi s citovanou hlaskou moc dospely neprijdes, protivniku ;-) (znamena to snad ze si protivny ??) ;-)

Rypnu si: takovy expert jako ty by v perfektne zabezpecenem systemu (software) hashoval hesla md5()-kou? :-P

Ano, MD5 je spolehlive a vykonne. Mas proti tomu neco?

radeji SHA1, preci jen je bezpecnejsi nez MD5, a soleni doporucuji nejen kuchari :)

md5-tkou to osolim treba s ID zaznamu v db:

$md5_pass = md5(md5($plain_pass).$record_id);

pri logovani se zjisti id zaznamu a heslo si prosolime stejne.

Blaznis, vyuka ma prave naucit, ako to prebieha v prevadzke. Ak sa niekto raz nauci pisat nezabezpeceny kod (a je rad ako hovoris), uz svoj sposob programovania nezmeni, kym sa mu nestane maler. Taketo "tutorialy" povazujem za horsie ako nic.

Nesouhlasim. Vyuka se ma zamerit na jeden problem a ten resit. Ne mast toho kdo se uci resenim desitek ruznych problemmu najednou. Jen by u toho melo byt uvedeno, ze dany priklad je prakticky nenasaditelny, protoze neresi a), b) a za c).

To zavisi pripad od pripadu. Nekde je oddelovani jiste na miste. Ale validovat vstupni hodnoty v uvedenem prikladu by bylo zcela trivialni, nijak zvlast by ho to nezeslozitilo, a hodne by to prospelo dobremu programatorskemu stylu ctenaru. Az (ctenari) uvidi, ze ve vsech prikladech se vzdy validuji vstupni data, tak to snad zacnou delat take...

Pokud by se autor skriptu nefixoval na MySQL, mohl by využít i jiné (a IMHO daleko praktičtější) možnosti, a to placeholders. Pak by mohl psát třeba

ibase_query($conn, 'insert into TBL(ID,NAME) values(?,?)', $id, $name)

a na nějakou SQL injection by mohl v klidu zapomenout až do chvíle, kdy by potřeboval, aby se data od uživatele promítla skutečně do dotazu, ne jen do parametrů (což je velmi zřídka). Nehledě na to, že při opakování téhož dotazu s různými parametry lze pak místo ibase_query použít ibase_prepare a ibase_execute, což běh skriptu urychlí.

Naprostej souhlas, tohle mi osobne prijde jako ta ficurka ktera rozhodne o tom ze se pouzije nejaky rozhrani co umi parametry, jako treba ODBC, JDBC nebo ADO... Pokud clovek parametrizuje tak se nestane ze se zapomene pri kontrole vstupu. A ve spojeni se stored procedurama (kdy ma dany db login pouzity na konexi pouze a jen prava na pousteni urcitych SP, zadny text query nema dovoleny) je ta databaze docela spolehlive zabezpecena proti utoku. Jedinej problem je u listu, ty se do SP cpou spatne.

clanek k nicemu. Kdo v PHP umi uz to 5 let zna. Kdo neumi tak neumi delat s DB. Nevim proc si pouzival zrovna DB kdyz ten problem v podstate o db neni, jen je to takhle slozitejsi. A kduz jsme u tech db tak s nima neumis delat ani ty kdyz davas pro kazdej lang novej sloupec :)

Nějak vám nerozumím. Opravdu tvrdíte, že kdo neumí PHP, neumí pracovat s databází?

P.S. zkuste aspoň občas používat čárky mezi větami, ulehčí to čtení příspěvků.

kdo neumi s PHP tak urcite neumi pracovat s databazema pomoci php

P.S. :)

Vidite, ja si vzdycky myslel ze SQL injection ma neco spolecneho s databazi, nikoli s PHP. Podstrkovani neceho neosetreneho nekam je obecne koledovani si o problem a jestli to udelate v PHP nebo ASP nebo treba pri pouzivani accessu je uplne jedno.

nekdo tady asi nepochopil, o cem ten clanek byl. predlozil jsem kus kodu, ktery kdosi prezentoval jako zpusob reseni jisteho problemu a poukazal na to, jak se da zneuzit v nadeji, ze si z nej ctenari vezmou ponauceni, jak se s databazemi v php nepracuje.

naprosto nechapu, co tady porad resite...

LOL. Ale tady prece o databaze nejde, kontrolovat udaje od uzivatelu se musi vsude at uz pouzivas databaze, textovy soubory nebo i kdyz vypisujes soubory. Kontrolovani udeaju od uzivatelu nema vlastne s db co delat. To je jen priklad jak to zneuzit. Takze fakt nechapu proc se clanek jmenuje jak se jmenuje

Me ten článek připadal zajimavý :)

VATA ;(