Index: phpdoc/hu/chapters/security.xml diff -u phpdoc/hu/chapters/security.xml:1.6 phpdoc/hu/chapters/security.xml:1.7 --- phpdoc/hu/chapters/security.xml:1.6 Sun Oct 29 06:10:25 2000 +++ phpdoc/hu/chapters/security.xml Sun Oct 29 08:12:12 2000 @@ -4,14 +4,14 @@ A PHP egy igen hatékony nyelv és feldolgozó program, akár a szerverben egy modulként van jelen, akár egy különálló - CGI futtatható állományként működik, képes elérni file-okat, futtatni - parancsokat és hálózati kapcsolatokat nyitni a szerveren. Ezek a - 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, és megfelelő kodolási - stílus használatával megadja neked a szabadság és biztonság megfelelő - kombinációját. + CGI futtatható állományként működik, képes elérni + fájlokat, futtatni parancsokat és hálózati kapcsolatokat nyitni a + szerveren. Ezek a 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, é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 @@ -57,14 +57,14 @@ - Rendszerfile-ok elérése: http://domain.nev/cgi-bin/php?/etc/passwd Az URL lekérési információja (query information), ami a kérdőjel (?) után található, parancssori paraméterként kerül átadásra a feldolgozónak. Általában a feldolgozók megnyitják, - és lefuttatják az első paraméterként adott file-t. + és lefuttatják az első paraméterként adott fájlt. Ha a PHP CGI futtatható állományként hívódik meg, nem veszi figyelembe @@ -78,23 +78,23 @@ Az elérési út információ (path information) az URL része, a - futtatható file neve után lévő + futtatható fájl neve után lévő /titkos/doc.html a CGI program által megnyitásra és futtatásra kerülő - file elérésének meghatározására használatos. + fájl elérésének meghatározására használatos. Tipikusan néhány web server beállítási lehetőség (Apache-ban: Action) használatos a kérések átirányítására a dokumentumhoz, mint a - http://domain.nev/titkos/script.php3 + http://domain.nev/titkos/szkript.php a PHP interpreter számára. Ezzel a beállítással a szerver először ellenőrzi az elérési engedélyeket a /titkos könyvtárra, és ezután állítja elő az átirányító kérést a http://domain.nev/cgi-bin/php/titkos/script.php3 + role="url">http://domain.nev/cgi-bin/php/titkos/szkript.php oldalra, amit így már a PHP feldolgoz. Azonban ha eredetileg is ebben a formában volt megadva a kérés, nem történik elérési ellenőrzés a /titkos/script.php3 file-ra, csak a - /cgi-bin/php file-ra. Ilyen módon + role="uri">/titkos/szkript.php fájlra, csak a + /cgi-bin/php fájlra. Ilyen módon bárki, aki elérheti a /cgi-bin/php címet, egyben tetszőleges védett dokumentumot is elérhet. @@ -114,7 +114,7 @@ - 1. eset : csak publikus file-ok + 1. eset : csak publikus fájlok Ha a szerveren nincs olyan tartalom, ami jelszó vagy IP alapú @@ -123,12 +123,12 @@ 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 - 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 + opciót a "configure" szkript számára. Meg kell győződnöd arról, hogy + a PHP szkriptjeid nem függnek egy speciális szkript hívási formától sem, mint a http://domain.nev/cgi-bin/php/dir/script.php3 + role="php">http://domain.nev/cgi-bin/php/dir/szkript.php vagy a http://domain.nev/dir/script.php3. + role="php">http://domain.nev/dir/szkript.php. Az átirányítás beállítása Apache alatt az @@ -140,7 +140,7 @@ 2. eset : az --enable-force-cgi-redirect használata Ez a fordítási opció megakadályozza, hogy bárki meghívja a PHP-t egy http://domain.nev/cgi-bin/php/titkos/script.php3. + role="php">http://domain.nev/cgi-bin/php/titkos/szkript.php. URL-el. Ehelyett a PHP csak akkor fog elfogadni egy ilyen kérést ha egy szerver átirányításban kapta. @@ -149,8 +149,8 @@ @@ -168,53 +168,53 @@ 3. eset : a doc_root vagy user_dir beállítása Aktív tartalom elhelyezése a normál dokumentumok között, - (pl. scriptek és futtatható állományok) veszélyes gyakorlat lehet. - Ha például valamilyen beállítási hiba miatt a scriptek ahelyett, + (pl. szkriptek és futtatható állományok) veszélyes gyakorlat lehet. + Ha például valamilyen beállítási hiba miatt a szkriptek ahelyett, hogy lefutnának hagyományos HTML dokumentumokként jelennek meg, mindenki számára tisztán látható válnak kódolási technikáid és pl. adatbázis jelszavaid. Ezért néhány rendszeradminisztrátor inkább egy külön könyvtárat jelöl ki, ami csak a PHP CGI által elérhető, és így mindig feldolgozásra kerül és nem jelenik meg - a script kódja. + a szkript kódja. Ha a fent leírt átirányítás azonosítási mód nem működik, - fontos, hogy egy különálló script doc_root-ot határozz meg, + fontos, hogy egy különálló szkript doc_root-ot határozz meg, ami nem azonos a web doc_root-al. - A PHP script dokumentumok gyökérkönyvtárát a + A PHP szkript dokumentumok gyökérkönyvtárát a doc_root konfigurációs beállítással határozhatod meg a - konfigurációs file-ban, vagy a + konfigurációs fájlban, vagy a PHP_DOCUMENT_ROOT környezeti változóban adhatod meg - ezt az értéket. Ha ez be van állítva a PHP CGI verziója a file + ezt az értéket. Ha ez be van állítva a PHP CGI verziója a fájl elérési útját a doc_root és a kérés elérési út információja (path information) alapján állítja elő, ami azt - jelenti, hogy ezen a könyvtáron kívül nem futtatható file. + jelenti, hogy ezen a könyvtáron kívül nem futtatható fájl. (kivéve a user_dir esetét). Egy másik itt használható opció a user_dir. Ha ez nincs megadva, csak a - doc_root szabályozza a megnyitható file-ok + doc_root szabályozza a megnyitható fájlok körét. Ekkor egy http://domain.nev/~user/doc.php3 URL nem a - "user" nevű felhasználó home könyvtárában lévő file-t keresi, hanem - a ~user/doc.php3 file-t keresi a + role="url">http://domain.nev/~user/doc.php URL nem a + "user" nevű felhasználó home könyvtárában lévő fájlt keresi, hanem + a ~user/doc.php fájlt keresi a doc_root alatt (igen, egy tilde karakterrel kezdődő könyvtárban [~]). Ha a user_dir meg van adva, például public_php, akkor a fenti http://domain.nev/~user/doc.php3 kérés a - doc.php3 nevű file-t fogja megnyitni a "user" + role="url">http://domain.nev/~user/doc.php kérés a + doc.php nevű fájlt fogja megnyitni a "user" nevű felhasználó home könyvtárában lévő public_php könyvtárban. Ha a "user" home könyvtára /home/user, - a lefuttatandó file a - /home/user/public_php/doc.php3 lesz. + a lefuttatandó fájl a + /home/user/public_php/doc.php lesz. A user_dir kifejtés a @@ -230,7 +230,7 @@ Egy rendkívül biztonságos lehetőség, ha a PHP feldolgozót valahol a web-en látható könyvtárakon kívülre teszed. Például a /usr/local/bin könyvtárba. Az egyetlen - igazi hátránya ennek az opciónak az, hogy minden PHP script + igazi hátránya ennek az opciónak az, hogy minden PHP szkript első sorának egy ehhez hasonló sort kell megadnod: @@ -240,7 +240,7 @@ ami megadja, hogy hol található a PHP feldolgozó, ami lefuttatja majd ezt - a scriptet. Ráadásul minden PHP scriptednek futási jogot kell adni. + a szkriptet. Ráadásul minden PHP szkriptednek futási jogot kell adni. Azaz úgy kell eljárni, mint bármilyen más CGI programmal, amit Perl, sh vagy bármilyen más nyelven írsz és a #! shell-escape mechanizmust használja sajátmaga futtatására. @@ -265,22 +265,22 @@ 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, + hogy egy rosszindulatú szkript 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 + .htaccess fájlt, 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. + fut, nem képes például vírus fájlok í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 + a fájlokat sem tudja írni, amit kellene, vagy nem tud végrehajtani adatbázis lekéréseket. @@ -295,30 +295,30 @@ - File-rendszer biztonság + Fájlrendszer 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 + különös figyelemmel a fájlokra é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 + mely fájlok olvashatóak a rendszerben. A mindenki számára + olvasható fájlokná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 + Mivel a PHP úgy készült, hogy felhasználói szintű fájlrendszer 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 + rendszer fájlokat olvassa, pl. az /etc/password fájlt. 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 + győződnöd a programjaidban, hogy az helyes fájlokat 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 + Nézzük a következő szkriptet, ahol a user megadja, hogy + le szeretne törölni egy fájlt 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. + fájlkezelésre, ezért az Apache usernek engedélyezni kell + a fájlok törlését a user felhasználó könyvtárában. @@ -326,7 +326,7 @@ 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 + tetszőleges usernevet és fájlt, í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 + ... fájlrendszer támadáshoz vezethet - Minden bejövő file-al kapcsolatos adat ellenőrzése. + Minden bejövő fájlal kapcsolatos adat ellenőrzése. - Egy fejlettebb script: + Egy fejlettebb szkript: - Biztonságosabb file ellenőrzés + Biztonságosabb fájl ellenőrzés A PHP által visszaadott hibaüzenetek általában hasznosak - a hibákat kereső fejlesztő számára, megjelölve a file-t, és + a hibákat kereső fejlesztő számára, megjelölve a fájlt, és a függvényt, ami hibás, megadva a megfelelő programsor számát. Ez az összes információ, amit ki lehet nyerni. @@ -427,19 +427,19 @@ Egy függvényhiba elárulhatja, hogy a rendszer milyen - adatbázsismotort használ, vagy hogy milyen programozói + adatbázismotort 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. + megtalálhatóak egy szkriptben. - A filerendszer vagy általános PHP hibák jelezhetik, hogy + A fájlrendszer 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. + a fájlok elrendezését és struktúráját. Három megoldási lehetőség adódik erre a problémára. Az első, @@ -466,7 +466,7 @@ - Biztos, hogy ez a script csak a kívánt file-okat fogja módosítani? + Biztos, hogy ez a szkript csak a kívánt fájlokat fogja módosítani? @@ -496,12 +496,12 @@ - Használható-e az adott script nem kívánatos formában? + Használható-e az adott szkript nem kívánatos formában? - Felhasználható-e más scriptekkel együtt egy negatív + Felhasználható-e más szkriptekkel együtt egy negatív hatás elérésére? @@ -512,7 +512,7 @@ - Kellőképpen átgondolva a fenti kérdéseket a script írásakor, + Kellőképpen átgondolva a fenti kérdéseket a szkript í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