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