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 PHPLehetsé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.
-