Én főleg a PHP-s oldalt látom nap mint nap, amit persze le lehet hurrogni hogy csak scriptnyelv, de a fő problémát abban látom, hogy a megrendelőnek fogalma sincs arról, hogy mit várjon el a fejlesztőtől. A másik probléma egynémely fejlesztő hozzáállása. A következő esetekre gondolok:
- A T. Megrendelő roppant nyomott áron akarja a csillagos eget is, ami rosszabb esetben csak a megrendelés közben derül ki és nincs is értelmes elvárása a szoftverkörnyezetre (esetünkben PHP és MySQL verzió és azokon belül egy-két feature esetleg). Itt nyilván az is bejön a képbe, hogy aki nagyon olcsón dolgozik, annak ez nem a sokadik komoly projektje.
- A fejlesztő(k) szerencsés esetben hajlandóak fél év garit vállalni a kódra, de általában a kérdés felmerülésekor elég bután néznek. Még hosszabb fejlesztési tapasztalatú cégek és fejlesztők is beleestek már ebbe. Például előfordult, hogy a PHP 5.3 update-ről körbement a hírlevél és a Joomlahuszárok elég nehezen vették a levegőt, amikor a bőven 1.5.15-nél régebbi Joomlájuk nem ment. Itt rögtön le is buktak, mert 1.5.26 körül hagyták abba annak a verziónak a supportját talán 1,5 éve. :)
- Ha rendesen halad is a fejlesztés, a T. Megrendelő oldaláról csak minimális funkciónális hibakeresésre van csak kapacitás (akár időbeli, akár tudásbeli). Ehhez rögtön hozzá is kell tennem, hogy elég nehéz lenne egy full biztonsági auditot kérni minden PHP-ban írt rendszerre, de legalább néhány gyakori mintával be lehetne próbálkozni.
- Aki bármilyen opensource CMS/keretrendszer/blogmotor/bármi felhasználásra adja a fejét, legalább tájékoztassa a T. Megrendelőt, hogy bizony ezek ellen hamar lesz célzott exploit, ha találnak valamit, és érdemes időszakosan frissítgetni. Ilyenkor jön a "rosszaszerver" és tsai, tudom tudom modsecurity és egyebek, de akkor meg azért anyáznak és azért "rosszaszerver", tehát ez nehéz kérdés innentől. Ha olyan a bug, akkor pedig hiába van mod_security, főleg egy osztott tárhelyes szerveren.
- Rengeteg csak úgy "csomagból felszórt" és kb. "huhezműködik" PHP telepítés fut, ahol még minimális korlátok sincsenek (pl. open_basedirre vagy a shell hivó függvények tiltása). Ezek nyilván nem oldják meg a hibás kód problémáját, de sokat segítene az általános helyzeten valszin, ha egy kicsit körültekintőbbek lennének ezek. Az is hozzátartozik, hogy a PHP tele van olyan opciókkal, amivel trükkösen elő lehet csalogatni mindenféle funkciót, pl. shell hívást. Ilyenre már sikerült is ráfutnom és nem volt őszinte a mosolyom, DE ami az érdekes, hogy a T. Ügyfél dupla trehánysága is kellett a probléma kiteljesédéhez.
- Mi a helyzet a sima egyszerű jelszó lopásokkal? Elsősorban az itt is rendszeresen előjövő Total Commander és más FTP kliens ini filejából kinyert FTP accountokra gondolok, aminél jobb nem is belegondolni, hogy ebből hány teljes shell account. Igazából ez is programozási probléma, mert a juzernek kell az elmenett jelszó, amit visszafejthető módon kell elmenteni. Ugyanez a gond, minden egyes nem-SSL-t használó protokollal, hiszen aki írta az pontosan tudta (legalábbis tudnia kéne), hogy lehallgathatóak. Az telefonokból esetlegesen kinyerhető jó eséllyel SSO jelegű AD-s Exchange jelszavakra még gondolni sem merek.