Vlákno názorů k článku Budeme mít "novou Adu a bezpečné PHP?" od anonym - kdyz kliknu na odkaz: <a href=""http://www.modflex.com/buxus/web/cz/Products/Development-Tools/modFlex/Freehosting/">freehostingu</a> a i jine.....

Rad bych se take zeptal v cem spociva nizka bezpecnost programovani v php ?

IMHO v tom, ze PHP toleruje (pokud ne primo podporuje) neprilis bezpecne programatorske navyky a postupy (napriklad nedostatecnou kontrolu vstupnich dat). Jen mam pochybnosti, jestli to dokaze za programatora vyresit jazyk.

V takovém ASP.NET se všechna data z formulářů procházejí a pokud obsahují "nebezpečné" konstrukce typu "<br>", systém vyhodí chybu s popisem, jak tyto data povolit. Podle mne je to zajímavé řešení, protože začátečníka trkne fakt, že by se měl o tyto věci starat a pokročilejší programátor si to automaticky vypne ve web.config...

je nekde nejaky prehledny popis toho na co si davat pozor (aneb jak to psat) - jde mi o to, nastuduju-li si knizku (kosek) o php apod. budu vedet jak rizika eliminovat nebo je php nebezpecne i nadale (neni-li, nepovazuji to za chybu php)

Jasne, hlavne v kodu nepouzivejte <br>, to je velmi riskantni programovaci technika. ;-)

Myslel jsem vstup od uživatele.

Je pravda, že PHP ve standardní konfiguraci svádělo nezkušené programátory k tvorbě velmi snadno nabouratelných aplikací. A také je pravda, že tvůrci PHP si to uvědomili a snaží se situaci změnit. Jenže konfigurace (a vůbec verze) PHP závisí většinou na správci hostingu, tudíž bude ještě nějakou dobu trvat, než se PHP zbaví tohoto dědictví z minula.

Ale nic to nemění na tom, že jakkoliv děravě nakonfigurované PHP není překážkou pro budování velmi solidních aplikací, pokud to programátor UMÍ. Záleží jen a jen na jeho schopnostech. A kde nejsou schopnosti, nepomůže ani modFlex ;-)

no jasne, me slo o to, jestlize ja budu dodrzovat postupy ktere tvurci pozaduji tak jestli je php bezpecne nebo jestli postupy musim obchazet pro psani bezpecnych aplikaci, .. proste mi nesedela ta vina na strane php
(zvlaste takto nepredpokladam u lidi pisici aplikace internet bankingu..)
OT: nejaky solidni komplexni zahranicni(EN) zdroj pro vyuku byste prosim nedoporucily? diky

Ne, můžeš úplně klidně psát aplikace v PHP. Ale pomalu si projdi třeba tuto sérii článků a zjistíš, na které věci si dávat pozor. Tyto techniky se většinou netýkají jen PHP (nebo třeba MySQL), ale vlastně všech platforem nebo databází, včetně těch velmi velmi drahých.

dikec

Řekl bych, že v rukou dobrého programátora není žádný jazyk nebezpečný.

Jde o to, ze jsme jenom lidi, takze nikdo neni "dobry programator" v tom smyslu, ze by nedelal zadne chyby. A pokud se v nejakem PHP preklepnu a misto "if (neplatnadata) die(x)" napisu "if(nwplatnadata) die(x)" tak to ma potencialne velmi neprijemne nasledky. (mod)Flex mi brani udelat podobnou chybu, cimz zvysuje tu bezpecnost. Ale otazka idealni miry takovych kontrol je evidentne veci osobniho vkusu.

On PHP uznává nedeklarované proměnné? Pokud vím, tak to VB bylo kdysi dost vyčítáno a VB.NET už je defaultně taky chce deklarovat...

ja nevim, pokud mam informace tak tohle se da vyresit pouzivanim nastroju pro psani kodu
(adekvatniho napr. html-kit u pro html.. ten pro php ted nemam na prstu.)

Promenou nemusite deklarovat. Na urovni nastaveneho hlaseni chyb zalezi, jestli Vas na to interpreter upozorni
- melo by se pouzivat pri vyvoji: error_reporting(E_ALL);
- zakaznikovi davat: error_reporting(0);

Vychozi nastaveni (asi E_NOTICE) je prasarna. Skoda, ze spousta PHPkaru bere zakladni nastaveni jako zaklad a nastaveni maximalni uroven povazuje za zbytecnou buzeraci.

Dalsi vtipne veci se v PHP daji provadet s register_globals=on, ale to je pomerne znama pohadka.

Áha... Zajímavé.
O Register globals vím z doby, kdy se u Psa na fórech objevila poměrně velká bitka, protože se admini rozhodli je vypnout...

Nastavení error_reporting = E_ALL by mělo být i na produkčním serveru. Jen to chce nastavit display_error = Off, aby se ty hlášky nezobrazovaly na stránce ale jen do logů. A samozřejmě se čas od času do těch logů podívat.

Kdyz si neumite nastavit ERROR_REPORTING v php.ini tak aby vam to php nehlasilo tak se pak nedivte.

Ale on uz je to takovy zdomacnely trik ze lide ve snaze prosazovat vlastni produkt ponekud zkresluji skutecnost, ze ano?

Proboha jaky zkreslovani skutecnosti? Faktem je, ze v PHP nedelam (az na par trivialnich a zcela ne-mission-critical programku), takze se v jeho konfiguraci opravdu nijak zvlast nevyznam (i kdyz o error_reporting vim). Jenze ono to IIANM hlasi teprve ve chvili pouziti, ne ve chvili "kompilace".
Hlavni pointa je ovsem v tom, ze PHP (a obdobne dalsi skriptovaci jazyky) maji velice vysokou toleranci vuci programatorovym chybam, coz vede k tomu, ze az ji programator udela (ne kdyz, vsichni delaji chyby), vsimne si ji hure/pozdeji, nez kdyby ho kompilator okamzite serval. (Osobni priklad: v jednom ze svych skriptu jsem si napr. po ne zrovna kratke dobe vsimnul, ze v jedne velice zridka vyuzivane vetvi programu pisu dice0 misto dice[0]. Jenze se to projevi az ve chvili, kdy se tahle vetev bude provadet, coz uz muze byt "u zakaznika", kde je error_reporting vypnuty.)
A samozrejme nejde jenom o nedeklarovane identifikatory, to byl nejjednodussi priklad. Stejne tak me IIRC necha PHP do jedne promenne chvilemi prirazovat cisla, chvilemi retezce a pote z ni udelat pole. Atd. atd. Nikomu nenutim jazyky se striktnimi kontrolami jako zasadne lepsi, ale to, ze se takhle jazyky daji delit a ze to nejake vyhody ma, to snad uznavaji vsichni, ne?

Jojo, ale taky by se dalo říct, že v rukou dobrého programátora není žádný jazyk bezpečný :)
Můj osobní názor: mod_perl rulez.

:-)
Můj osobní názor: .NET rulez ... a jako jazyk C# ... Perl by taky šel :-)

Pokud aplikace v .NET delaji nedouci (presne ti sami co casto pobihaji po forech o PHP a zadaji kompletni kody) tak ta aplikace stoji za prd (uplne stejne jako kdyby ji delal v PHP). Coz ovsem neni problem jazyka.

Samozřejmě... Já si jen myslím, že pro douka bude .NET nejlepší. Což je můj soukromý názor a nehodlám se o tom hádat...