Index: phpdoc/hu/chapters/security.xml diff -u phpdoc/hu/chapters/security.xml:1.4 phpdoc/hu/chapters/security.xml:1.5 --- phpdoc/hu/chapters/security.xml:1.4 Sat Oct 14 06:26:30 2000 +++ phpdoc/hu/chapters/security.xml Sat Oct 28 09:09:00 2000 @@ -9,8 +9,9 @@ tulajdonságok alapesetben veszélyessé is tehetik más, a webszerveren futó alkalmazások számára. A PHP-t úgy fejlesztették, hogy biztonságosabb legyen CGI programok írására, mint a Perl vagy C nyelvek. A PHP a fordítási - és futásidejű beállítások helyes választásával megadja neked a - szabadság és biztonság megfelelő kombinációját. + és futásidejű beállítások helyes választásával, és megfelelő kodolási + stílus használatával megadja neked a szabadság és biztonság megfelelő + kombinációját. Mivel sok különböző formája van a PHP használatának, számos @@ -18,12 +19,26 @@ lehetőségek nagy száma garantálja, hogy a PHP-t sokféle célra felhasználd, de egyben azt is jelenti, hogy ezek és a szerver beállításainak kombinációi kritikus helyzeteket teremthetnek. - Ez a fejezet kitér a különböző konfigurációs beállítás-kombinációkra, - és azokra az esetekre, amikor ezek biztonsággal használhatóak. + + A beállítások sokszínűsége egyenlő mértékű a kódok sokszínűségével. + A PHP használható teljes szerver alkalmazások készítésére, + egy shell user minden lehetőségével, vagy használható + egyszerű server side include-oknál, kis kockázattal egy + szigorúan ellenőrzött rendszerben. Az, hogy hogyan kell + kialakítani egy könyezetet, milyen biztonságosan, nagyban a PHP + fejlesztőn múlik. + + + Ez a fejezet először a különböző beállítási-lehetőség + kombinációkat tárgyalja, és azokat a helyzeteket, ahol + ezek biztonságosan használhatóak. Utána néhány kódolási + problémát mutat be, amik biztonságosság szempontjából + érdekesek lehetnek. Végül némi általános tanács következik. + - CGI futtatható állomány + CGI futtatható állományként telepített PHP Lehetséges támadások @@ -86,7 +101,7 @@ A PHP esetében az --enable-force-cgi-redirect + linkend="install.configure.enable-force-cgi-redirect">--enable-force-cgi-redirect fordítási opció, a doc_root és user_dir konfigurációs lehetőségek @@ -107,7 +122,7 @@ beállításokra. Ha a szerver nem engedélyezi az átirányításokat, illetve ha a szervernek nincs módja biztonságos átirányítással küldeni a kérést a PHP számára, megadhatod az --enable-force-cgi-redirect + linkend="install.configure.enable-force-cgi-redirect">--enable-force-cgi-redirect opciót a "configure" script számára. Meg kell győződnöd arról, hogy a PHP script-jeid nem függnek egy speciális script hívási formától sem, mint a PATH_INFO és a PATH_TRANSLATED információkat, a PHP feldolgozót az --enable-discard-path + linkend="install.configure.enable-discard-path">--enable-discard-path "configure" opcióval kell fordítani. @@ -242,13 +257,317 @@ - Apache modul + Apache modulként telepített PHP Ha a PHP-t Apache modulként használod, örökli az Apache - felhasználói engedélyeket (tipikusan a "nobody" nevű user alatt fut). + felhasználói engedélyeket (tipikusan a "nobody" nevű user + alatt fut). Ennek többféle hatása van a biztonságra és az azonosításra. + Például ha PHP-t használsz egy adatbázis eléréséhez, annak ellenére, + hogy az adatbázisnak beépített azonosítása van, az adatbázist elérhetővé + kell tenned a "nobody" user számára is. Ez azt jelenti, + hogy egy rosszindulatú script elérheti, és módosíthatja az adatbázist, + akár felhasználói név és jelszó nélkül is. Lehetséges, hogy egy + keresőrobot beleakadjon az adatbázis-adminisztrációs lapodba, + és kiürítse az összes adatbázist. Természetesen ez ellen + védekezhetsz Apache azonosítási technikákkal, vagy elkészítheted + a saját elérési modelledet LDAP segítségével, készíthetsz + .htaccess file-t, stb. és a PHP kódoddal együtt kezelheted + ezeket is. + + + Általában, ha a biztonságot akkora szintre tudjuk emelni, hogy + a PHP user (ebben az esetben az Apache user) igen kis kockázattal + fut, nem képes például vírus file-ok írására a user könyvtárakba. + Letilthatjuk számára egy prívát adatbázis elérését vagy + megváltoztatását. Tipikusan ebben a helyzetben már azokat + a file-okat sem tudja írni, amit kellene, vagy nem tud + végrehajtani adatbázis lekéréseket. + + + Egy gyakori hiba ezen a ponton, hogy az Apache-nak root jogokat adnak. + + + Az Apache user jogainak root szintre bővítése különösen + veszélyes, és töknreteheti a teljes rendszert, tehát sudo, + chroot vagy más hasonló eszközök használata elkerülendő, + ha nem vagy biztonsági szakember. + + + + + File-rendszer biztonság + + A PHP tiszteli a rendszerbe épített biztonsági megoldásokat, + különös figyelemmel a file-okra és könyvtárakra beállított + jogosultságokra. Ez lehetőséget ad arra, hogy megszabd, + mely file-ok olvashatóak a rendszerben. A mindenki számára + olvasható file-oknál ügyelni kell arra, hogy ne tartalmazzanak + olyan fontos adatot, amit nem szabad, hogy elolvasson + akármelyik user a rendszeren. + + + Mivel a PHP úgy készült, hogy felhasználói szintű file-rendszer + hozzáférést ad, lehetséges olyan program készítése, ami a + rendszer file-okat olvassa, pl. az /etc/password file-t. Ez + maga után von egy nyilvánvaló következtetést, hogy meg kell + győződnöd a programjaidban, hogy az helyes file-okat olvasod + illetve írod. + + + Nézzük a következő scriptet, ahol a user megadja, hogy + le szeretne törölni egy file-t a könyvtárában. Ez többnyire + egy webes felületet jelent, ahol egy PHP program használatos + filekezelésre, ezért az Apache usernek engedélyezni kell + a file-ok törlését a user felhasználó könyvtárában. + + + + A helytelen változó használat .... + + +]]> + + + Mivel a usernév egy HTML űrlapból érkezik, a felhasználó beírhat + tetszőleges usernevet és file-t, így akár más könyvtárát + is manipulálhatja. Ebben az esetben általában valamilyen + felhasználó-azonosítási eljárást kell alkalmaznod. Lássuk, + mi történik, ha a beadott változók a "../etc/" és a + "passwd". A kód akkor így alakulna (az adatokat + behelyettesítve): + + ... file-rendszer támadáshoz vezethet + + +]]> + + + Két fontos komponens van, ami hatással van arra, hogy ilyen + megtörténhet vagy sem: + + + + Csak korlátozott jogok beállítása a PHP web usernek. + + + + + Minden bejövő file-al kapcsolatos adat ellenőrzése. + + + + Egy fejlettebb script: + + Biztonságosabb file ellenőrzés + + +]]> + + + + + + + Hibajelzés + + Egy szokásos támadási technika minél több információ begyűjtése + a rendszerről. Ezt úgy próbálják megoldani, hogy helytelen + adatokat küldenek be, és rögzítik a hibaüzenetek típusait + és környezetüket. Ez lehetőséget ad a crackernek, hogy + elég információt gyűjtsön a rendszerről, és meghatározza + a lehetséges gyenge pontokat. + + + A PHP által visszaadott hibaüzenetek általában hasznosak + a hibákat kereső fejlesztő számára, megjelölve a file-t, és + a függvényt, ami hibás, megadva a megfelelő programsor számát. + Ez az összes információ, amit ki lehet nyerni. + + + Például a hibaüzenetek nagyrészéből beazonosítható, hogy + a rendszer PHP-t használ. Ha a támadó egy .html oldalt látott, + és ismert hibákat kihasználva meg akarta tudni, hogy + milyen alkalmazást használ a rendszer, hibás adatokat beküldve + azonosíthatja, hogy az oldalt egy PHP program állította elő. + + + Egy függvényhiba elárulhatja, hogy a rendszer milyen + adatbázsimotort használ, vagy hogy milyen programozói + stílussal készült az adott weblap. Ez mélyebb kutatásokra + ad lehetőséget nyitott adatbázisportok irányában, vagy + tipikus hibák illletve gyengeségek keresését jelentheti. + Különböző hibás adatok küldésével a támadó meg tudja + állapítani, hogy milyen sorrendben végzed az azonosításokat + (a hibák sorszámaiból). Ezzel könnyen a gyenge pontok is + megtalálhatóak egy scriptben. + + + A filerendszer vagy általános PHP hibák jelezhetik, hogy + milyen jogokkal rendelkezik a webszerver, és megmutathatja + a file-ok elrendezését és struktúráját. + + + Három megoldási lehetőség adódik erre a problémára. Az első, + hogy vizsgáld meg alaposan a függvényeidet, és próbáld + meg elkerülni a hibákat. A második, hogy kapcsold ki a + hibajelentést a teljes kódra. A harmadik, hogy használd + a PHP testreszabható hibajelentési funkcióit, hogy saját + hibakezelőket definiálj. A már megtett biztonsági + intézkedésektől függően esetleg mindhárom fenti módszer + közül választhatsz. + + + + + Felhasználótól érkező adatok + + A legtöbb probléma sok PHP programban nem a nyelvben rejlik, hanem + abból fakad, hogy a kód nem a biztonságosságot szem előtt tartva + készült. Ezért te mindig szánj megfelelő időt arra, hogy ellenőrizd, + hogy egy adott kódrészletre milyen hatással lehet egy váratlan hibás + adat. + + Veszélyes változóhasználat + + +]]> + + + Mindig alaposan meg kell vizsgálnod a feljhasználók + által beadott adatokat, feltéve magadnak a következő kérdéseket: + + + + Biztos, hogy ez a script csak a kívánt file-okat fogja módosítani? + + + + + Előfordulhat azon a ponton, hogy szokatlan vagy nem kívánatos + adat jelenjen meg? + + + + + Használható-e az adott script nem kívánatos formában? + + + + + Felhasználható-e más scriptekkel együtt egy negatív + hatás elérésére? + + + + + Megfelelően naplózásra kerülnek-e a tranzakciók + (elérések, változtatások)? + + + + Kellőképpen átgondolva a fenti kérdéseket a script írásakor, + megkímélheted magad, hogy később végiggondolva a problémákat + szerencsétlen módon újra kelljen írnod a teljes kódot + a biztonságosság növelése érdekében. Ezzel sem tudod + garantálni a rendszer biztonságát, de segíthetsz a + növelésében/fenntartásában. + + + + + Általános meggondolások + + Lehetetlen megalkotni egy teljesen biztonságos rendszert, ezért + az általános hozzáállás a kockázat és használhatóság megfelelő + súlyozása. Ha minden felhasználó által beadott adat elfogadásához + kétféle biometrikus azonosítás szükséges (mint a retina vagy + ujjlenyomat ellenőrzés), akkor rendkívül alapos rendszert + készítettél. Azonban így egy alapos kérdőív kitöltése fél órába + is beletelhet, ami arra fogja sarkalni a felhasználót, hogy + megpróbálja megkerülni az azonosítást. A jó biztonság elég + ahhoz, hogy megfeleljen az elvárásoknak anélkül, hogy + megakadályozná a felhasználót abban, hogy elvégezze a munkáját. + Valójában néhány biztonsági támadás csupán az eredeti célon + túllőt biztonsági rendszerek kihasználásából áll. + + + Egy modás, amire emlékezned kell: A rendszer olyan erős, mint + a leggyengébb láncszem. Ha minden művelet naplózásra kerül, + idővel, eléréssel, típussal, stb., de a felhasználót csak + egy egyszerű cookie-val azonosítod, keveset érsz a a + naplókkal. + + + Amikor tesztelsz, vedd figyelembe, hogy nincs lehetőséged + minden hibát figyelembe venni, még a legegyszerűbb oldalakon + sem. A bejövő adat akár teljesen más is lehet, mint amit + elvársz, pl. egy rosszkedvű alkalmazott, vagy egy több hónapos + szabadidővel rendelkező cracker, akár egy billentyűzeten + végigsétáló macska hatásaként. Ezért célszerű logikusan + végigtekinteni a kódon, és megkeresni azokat a pontokat, + ahol nem várt adatok léphetnek be, és megnézni, hogy + milyen manipulációkon megy keresztül csökkentve vagy + felerősítve a hiba jelentőségét. + + + Az Internet tele van olyan emberekkel, akik úgy akarnak + nevet szerezni maguknak, hogy feltörik a kódodat, + működésképtelenné teszik a site-odat, értelmetlen adatokat + küldenek be, és más módokon teszik érdekessé a napodat. + Nem érdekes, hogy nagy vagy kis site-od van, célpont lehetsz, + mert online vagy, mivel van szervered, amihez csatlakozni + lehet. Sok cracker program nem tesz különbséget méret + szerint, csak végiglépkednek az IP blokkokon áldozatokat + keresve. Próbálj meg nem közöttük lenni. -