cvs: phpdoc /hu/chapters config.xml security.xml
| From: | Gyozo Papp | Date: | Thu, 20 Dec 2001 01:20:51 +0000 |
| Subject: | cvs: phpdoc /hu/chapters config.xml security.xml | ||
| Groups: | php.doc | ||
| Request: | Send a blank email to phpdoc+get-969340114@lists.php.net to get a copy of this message | ||
pgerzson Wed Dec 19 20:20:51 2001 EDT
Modified files:
/phpdoc/hu/chapters security.xml config.xml
Log:
catching up config and security chapters
Index: phpdoc/hu/chapters/security.xml diff -u phpdoc/hu/chapters/security.xml:1.14 phpdoc/hu/chapters/security.xml:1.15 --- phpdoc/hu/chapters/security.xml:1.14 Wed Dec 12 15:50:54 2001 +++ phpdoc/hu/chapters/security.xml Wed Dec 19 20:20:50 2001 @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="iso-8859-2"?> -<!-- EN-Revision: 1.19 Maintainer: goba Status: ready --> +<!-- EN-Revision: 1.38 Maintainer: pgerzson Status: ready --> <chapter id="security"> <title>Biztonság</title> @@ -35,13 +35,63 @@ fejlesztõn múlik. </simpara> <simpara> - 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éhány általános tanács következik. + Ez a fejezet néhány biztonsági tanácsot tárgyal, a különbözõ + beállítási lehetõségeket és azokat a helyzeteket tárja fel, amelyekben + ezeket biztonsággal lehet használni. Utána néhány kódolási szempontot + vesz át a különbözõ szintû biztonságosság szempontjából </simpara> + <sect1 id="security.general"> + <title>Általános szempontok</title> + <simpara> + A teljesen biztonságos rendszer kialakítása tulajdonképpen lehetlenség, + ezért a biztonsági területen alkalmazott megközelítés a kockázat és a + használhatóság közti egyensúly megteremtése. Ha minden a felhasználó + által küldött adat két biometrikus érvényesítést (pl. retina- és + ujjlenyomatvizsgálatot) igényel, akkor igen magas szintû a rendszer + "felelõsségre vonhatósága" (accountability). Ez azonban azt jelentené, hogy + félórába telne kitölteni egy meglehetõsen összetett ûrlapot, ami arra + ösztökélné a felhasználókat, hogy valahogy megkerüljék ezt a védelmet. + </simpara> + <simpara> + A legjobb védelem gyakran a kevésbé alkalmatlankodó és nem feltûnõ, + hogy megfeleljen a követelményeknek anélkül, hogy megakadályozná a + felhasználókat a munkájuk elvégzésében vagy túlterhelné a program íróit + annak túlzott mérvû bonyolultsága. Valójában néhány biztonsági támadás + pusztán a kiaknázása az olyasfajta túlságosan is kiépített védelemnek, amely + hajlamos elerodálódni az idõvel. + </simpara> + <simpara> + Egy mondatot érdemes megjegyezni: A rendszer csakis annyira jól védett, + amennyire a leggyengébb láncszeme. Ha minden tranzakciót hevesen + naplóz idõ, hely és tranzakciótípus alapján is, de a felhasználó csak + egy egyszerû süti (cookie) alapján azonosítja, akkor a felhasználók + tranzakciónaplón belüli elõfordulásának érvényessége, megbízhatósága + igen gyenge. + </simpara> + <simpara> + Amikor tesztelsz, vedd figyelembe, hogy nem vagy képes minden lehetõséget + kipróbálni már a legegyszerûbb oldalak esetén sem. Az általad várt adatok + teljesen különbözõek és összefüggéstelenek azoktól, amelyeket egy zsémbelõdõ + alkalmazott képes elküldeni, vagy amelyeket egy szoftverkalóz (cracker) több + havi munkájával állít össze, vagy ami nem más, mint egy házimacska + billenytyûzeten hagyott "lábnyoma". Ezért a legjobb, ha a programot logikai + nézõpontból közelíted meg, hogy sikerüljön észrevenni, hol jöhetnek elõ nem + várt adatok és azok a továbbiakban hogyan módosulhatnak, tûnhetnek el vagy + erõsödhetnek fel a hatásuk. + </simpara> + <simpara> + Az Internet tele van olyan emberekkel, akik azzal akarnak maguknak nevet + szerezni, hogy feltörik az oldalaidat, tönkreteszik a programjaidat, nem + helyénvaló tartalommal töltik fel azokat, mellesleg egy - két izgalmas(?) + napot szerezve ezzel Neked. Nem számít, hogy kis vagy nagy webhelyrõl van szó, + elég indok a támadásra, hogy rá vagy kapcsolva a hálóra, és van egy szervered, + amelyhez csatlakozni lehet. Sok kódtörõ program nem foglalkozik a méretekkel, + egyszerûen csak nagy mennyiségû IP blokkokra vadászik áldozatokat keresve ezzel + magának. Próbálj meg nem egy lenni közülük! + </simpara> + </sect1> + <sect1 id="security.cgi-bin"> <title>CGI futtatható állományként telepített PHP</title> @@ -284,14 +334,15 @@ <simpara> Á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 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 fájlokat sem tudja írni, amit kellene, vagy nem tud - végrehajtani adatbázis lekéréseket. + fut, nem képes például akármilyen fájlok írására a user könyvtárakba. + Letilthatjuk számára egy adatbázis elérését vagy megváltoztatását. + Tipikusan ebben a helyzetben már azokat a fájlokat sem tudja írni, + amit kellene, vagy egyaránt nem tud végrehajtani jó és rosszindulatú + adatbázis tranzakciókat. </simpara> <simpara> - Egy gyakori hiba ezen a ponton, hogy az Apache-nak root jogokat adnak. + Egy gyakori hiba ezen a ponton, hogy az Apache-nak root jogokat adnak vagy + valamilyen egyéb módon bõvítik az Apache jogait / lehetõségeit. </simpara> <simpara> Az Apache user jogainak root szintre bõvítése különösen @@ -299,6 +350,12 @@ chroot vagy más hasonló eszközök használata elkerülendõ, ha nem vagy biztonsági szakember. </simpara> + <simpara> + Van néhány egyszerûbb megoldás is. Az <link linkend="ini.open-basedir">open_basedir</link> + használatával szabályozni lehet, hogy mely könyvtárakat olvashatja a PHP. + Ki lehet jelölni ún. csak apache-s területeket, hogy minden web alapú mûveletet + ide ezekre a nem rendszer- és nem felhasználói fájlokra korlátozz. + </simpara> </sect1> <sect1 id="security.filesystem"> @@ -334,7 +391,7 @@ <![CDATA[ <?php // egy fájl törlése a user könyvtárából -$usernev = $user_altal_beadott_nev; +$usernev = $HTTP_POST_VARS["user_altal_beadott_nev"]; $konyvtar = "/home/$usernev"; $torlendo_file = "$userfile"; unlink ($konyvtar/$torlendo_file); @@ -388,8 +445,8 @@ <?php // egy fájl törlése akárhonnan, ahol a PHP usernek // joga van erre. -$usernev = $HTTP_REMOTE_USER; // ez a user azonosított neve - // (ha volt elõtte azonosítás) +$usernev = $HTTP_SERVER_VARS['REMOTE_USER']; // ez a user azonosított neve + // (ha volt elõtte azonosítás) $konyvtar = "/home/$usernev"; @@ -397,7 +454,7 @@ unlink ($konyvtar/$torlendo_file); $fp = fopen("/home/logging/filedelete.log","+a"); // törlés naplózása -$logstring = "$HTTP_REMOTE_USER $konyvtar $torlendo_file"; +$logstring = "$usernev $konyvtar $torlendo_file"; fputs ($fp, $logstring); fclose($fp); @@ -405,24 +462,31 @@ ?> ]]> </programlisting> - </example> - Esetleg egy jobban testreszabott ellenõrzést is készíthetsz: + </example> + Mindamellett, ez sem mentes a hiányosságoktól. Ha az általad használt + hitelesítési módszer (authentication) megengedi a felhasználóknak, hogy + saját login naplót vezessenek, akkor ha egyikük a "../etc/" -t választja + a rendszer védtelenné válik. Ebbõl kiindulva, egy jobban testreszabott + ellenõrzést is készíthetsz: <example> <title>Biztonságosabb fájlnév-ellenõrzés</title> <programlisting role="php"> -<![CDATA[ -<?php -$username = getenv("REMOTE_USER"); -$homedir = "/home/$username"; - -if (!ereg('^[^./][^/]*$', $userfile)) - die('rossz fájlnév'); //nem hajtjuk végre a törlést - -//etc... -?> -]]> + <![CDATA[ +<?php +$usernev = $HTTP_SERVER_VARS['REMOTE_USER']; // hitelesites +$homedir = "/home/$usernev"; $homedir = "/home/$usernev"; + +if (!ereg('^[^./][^/]*$', $userfile)) + die('rossz fájlnév'); // vége, nincs feldolgozás + +if (!ereg('^[^./][^/]*$', $usernev)) + die('rossz usernev'); // vége, nincs feldolgozás +//stb... +?> </programlisting> - </example> + </example> + </para> + <para> A használt operációs rendszertõl függõen széles a védeni kívánt fájlok skálája, beleértve az eszköz hivatkozásokat (/dev/ vagy COM1), konfigurációs fájlokat (/etc/ és az .ini fájlok), jól ismert @@ -434,15 +498,32 @@ <sect1 id="security.errors"> <title>Hibajelzés</title> - <simpara> + <para> + A PHP biztonsági kérdések felõl a hibajelzéseknek két oldaluk van. + Az egyik hasznos a védelem növelése szempontjából, a másik káros rá. + </para> + <para> 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. - </simpara> - <simpara> + a lehetséges gyenge pontokat. Ha például a támadó összeszedegett + elég információt az elõzõ ûrlap kitöltések alapján, akkor + megpróbálhatja a változókat felülírni vagy megváltoztatni õket: + <example> + <title>Változók elleni támadás egy HTML oldallal</title> + <programlisting role="php"> +<![CDATA[ +<form method="post" action="tamadas_celpontja?usernev=rosszize&jelszo=rosszize"> +<input type="hidden" name="usernev" value="rosszize"> +<input type="hidden" name="jelszo" value="rosszize"> +</form> +]]> + </programlisting> + </example> + </para> + <para> A PHP által visszaadott hibaüzenetek általában hasznosak 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. @@ -452,16 +533,35 @@ <function>highlight_file</function> függvényeket a fejlesztés során hibakeresésre is használja, de egy élesben lévõ webhelyen ez rejtett változókat, ellenõrizetlen kódokat, - és más veszélyes információkat fedhet fel. - </simpara> - <simpara> + és más veszélyes információkat fedhet fel. Kifejezetten veszélyes + ismert forrású beépített hibakezelõvel rendelkezõ kódok használata. + Ha a támadó rájön, milyen általános technikát használsz, akkor + megpróbálhatja a nyers erõre alapozva feltörni az oldalt a + különbözõ megszokott hibakeresõ (debugging) változók elküldésével: + <example> + <title>Szokványos hibakeresõ változók kihasználása</title> + <programlisting role="php"> +<![CDATA[ +<form method="post" action="tamadas_celpontja?errors=Y&showerrors=1"&debug=1"> +<input type="hidden" name="errors" value="Y"> +<input type="hidden" name="showerrors" value="1"> +<input type="hidden" name="debug" value="1"> +</form> +]]> + </programlisting> + </example> + </para> + <para> + A hibakezelés módjától függetlenül, az a lehetõség, hogy egy rendszerben + hibák után kuthatnak, odavezet, hogy a támadók is több információhoz + jutnak. Az általános hibaüzenetek nagyrészébõl például 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õ. - </simpara> - <simpara> + </para> + <para> Egy függvényhiba elárulhatja, hogy a rendszer milyen adatbázismotort használ, vagy hogy milyen programozói stílussal készült az adott weblap. Ez mélyebb kutatásokra @@ -471,15 +571,15 @@ állapítani, hogy milyen sorrendben végzed az azonosításokat (a hibák sorszámaiból). Ezzel a gyenge pontok is könnyen megtalálhatóak egy szkriptben. - </simpara> - <simpara> + </para> + <para> A fájlrendszer vagy általános PHP hibák jelezhetik, hogy milyen jogokkal rendelkezik a webszerver, és megmutathatják a fájlok elrendezését és struktúráját. A fejlesztõ által írt hibás kód súlyosbíthatja a helyzetet, régebben 'rejtett' információk könnyû kiderítését téve lehetõvé. - </simpara> - <simpara> + </para> + <para> 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 @@ -488,9 +588,111 @@ 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. - </simpara> + </para> + <para> + Hogy megelõzd a bajt, hasznát veheted a PHP saját + <function>error_reporting</function> függvényének, ami segít + biztonságosabbá tenni a programodat és megtalálni a változók + vészelyeket rejtõ használati formáit. A bevezetés elõtti tesztelés + során E_ALL beálllítással gyorsan meg lehet találni azokat a pontokat, + ahol a változóid könnyen és/vagy rosszindulatúan módosíthatók. Ha + már kész vagy a program bevezetésére, akkor a E_NONE-t használva + teljesen el tudod szigetelni a kódodat a további vizslatásoktól. + <example> + <title>Veszélyes változók felderítése az E_ALL segítségével</title> + <programlisting role="php"> +<![CDATA[ +<?php +if ($usernev) { // nincs inicializálva vagy ellenõrizve használat elõtt + $jo_belepes = 1; +} +if ($jo_belepes == 1) { // ha az elõzõ feltétel hamis, nincs inicializálva vagy ellenõrizve használat elõtt + fpassthru ("/nagyon/kenyes/adatok/index.html"); +} +?> +]]> + </programlisting> + </example> + </para> </sect1> - + + <sect1 id="security.registerglobals"> + <title>Globálisan is elérhetõ változók (Register Globals) használata</title> + <para> + A biztonság növelésére használható a PHP egyik lehetõsége: a + <link linkend="ini.register-globals">register_globals</link> = off beállítás + használata. Ennek a kikapcsolása azt jelenti, hogy nem "szennyezi" a PHP + kódot bármely felhasználótól jövõ változó, és így csökken a potenciális + támadó által befolyásolható változók köre. Még több idõt kell azzal tölteniük, + hogy kitalálják a változók feltöltésének módját, és a belsõ változóid + hatékonyan elkülönülnek a felhasználó által elküldött adatoktól. + </para> + <para> + While it does slightly increase the amount of effort required + to work with PHP, it has been argued that the benefits far + outweigh the effort. + <example> + <title>register_globals=off nélkül</title> + <programlisting role="php"> +<![CDATA[ +<?php +if ($usernev) { // felhasználható által hamisítható get/post/cookies + $jo_belepes = 1; +} + +if ($jo_belepes == 1) { // felhasználható által hamisítható get/post/cookies + fpassthru ("/nagyon/kenyes/adatok/index.html"); +} +?> +]]> + </programlisting> + </example> + <example> + <title>register_globals = off használatával</title> + <programlisting role="php"> +<![CDATA[ +<?php +if($HTTP_COOKIE_VARS['usernev']){ + // csak sütiként jöhet, hamisítva vagy épp ellenkezõleg + $jo_belepes = 1; + fpassthru ("/nagyon/kenyes/adatok/index.html"); +} +?> +]]> + </programlisting> + </example> + Okosan használva, még azt képes lehet jelezni, ha hamisítást + kíséreltek meg. Ha elõre tudod, hogy mely változóknak honnan + kell érkezniük, megvizsgálhatod, hogy vajon más módon nem próbálták-e + meg elküldeni ezt a változót. Ez nem garantálja, hogy az adatok + nem hamisíthatók, azonban megköveteli a támadótól, hogy az rátaláljon + a megfelelõ hamisítási módszerre. + <example> + <title>Egyszerû változó-átvétel felfedése</title> + <programlisting role="php"> +<![CDATA[ +<?php +if ($HTTP_COOKIE_VARS['usernev'] && + !$HTTP_POST_VARS['usernev'] && + !$HTTP_GET_VARS['usernev'] ) { + // egyéb usernev azonosítások elvégzése ... + $jo_belepes = 1; + fpassthru ("/nagyon/kenyes/adatok/index.html"); +} else { + mail("admin@example.com", "Lehetséges betörési kísérlet", $HTTP_SERVER_VARS['REMOTE_ADDR']); + echo "Védelmi szabályok megszegése, adminisztrátor értesítve."; + exit; +} +?> +]]> + </programlisting> + </example> + Természetesen register_globals egyszerû kikapcsolása nem jelenti azt, hogy + a kód biztonságos. Minden beérkezõ adatot valamilyen egyéb módon ellenõrizni + kell. + </para> + </sect1> + <sect1 id="security.variables"> <title>Felhasználótól érkezõ adatok</title> <para> @@ -508,7 +710,7 @@ // talán valaki máséból? unlink ($ordogi_valtozo); -// Az elérés naplózása... vagy nem? +// Az elérés naplózása... vagy egy /etc/passwd bejegyzésé? fputs ($fp, $ordogi_valtozo); // Valami egyértelmû dolog futtatása.. vagy rm -rf *? @@ -570,51 +772,54 @@ </para> </sect1> - <sect1 id="security.general"> - <title>Általános meggondolások</title> - <simpara> - 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. - </simpara> - <simpara> - Egy mondá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û sütivel azonosítod, keveset érsz a naplókkal. - </simpara> - <simpara> - Amikor kipróbálod a kódokat, 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. - </simpara> - <simpara> - 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 webhelyedet, értelmetlen adatokat - küldenek be, és más módokon teszik érdekessé a napodat. - Nem számít, hogy nagy vagy kis webhelyed van, célpont lehetsz, - mert online vagy, mivel van webkiszolgálód, 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. - </simpara> + <sect1 id="security.hiding"> + <title>PHP elrejtése</title> + <para> + Néhány egyszerû módszerrel elrejtheted azt, hogy PHP-t használsz, + így lassítva le a támadót, aki fel akarja deríteni a rendszered + gyenge pontjait. A php.ini-ben az expose_php = off beállítással + csökkentheted ezeket az információkat. + </para> + <para> + Másik taktika, hogy a webszervert (pl. apache) úgy állítod be + a .htaccess-en vagy az apache konfigurációs fájlában, hogy + különbözõ típusú fájlokat futtass a PHP-n keresztül. Más + félrevezetõ fájlkiterjesztéseket használhatsz: + <example> + <title>PHP elrejtése más nyelvként</title> + <programlisting role="apache-conf"> +<![CDATA[ +# úgy tûnik, mintha PHP helyett mást használnál +AddType application/x-httpd-php .asp .py .pl +]]> + </programlisting> + </example> + vagy teljesen ismeretlent is megadhatsz: + <example> + <title>ismeretlen típusok használata PHP fájlok kiterjesztéseként</title> + <programlisting role="apache-conf"> +<![CDATA[ +# PHP kódok teljesen ismeretlen típusúnak tûnnek +AddType application/x-httpd-php .bop .foo .133t +]]> + </programlisting> + </example> + vagy html kódként is elrejtheted, amely csekély teljesítménycsökkenést okoz, + mivel minden html oldal átmegy a PHP-n: + <example> + <title>html típus használata PHP fájlkiterjesztésként</title> + <programlisting role="apache-conf"> +<![CDATA[ +# PHP kódok html típusúnak tûnnek +AddType application/x-httpd-php .htm .html +]]> + </programlisting> + </example> + Ahhoz, hogy ez jól mûködjön, minden PHP fájlodat át kell nevezni + a fenti kiterjesztések valamelyikének megfelelõen. Mivel ez is az + elrejtõzésen / ismeretlenségen alapuló védelmi forma, kevés hátránya + mellett csekély megakadályozó intézkedést jelent. + </para> </sect1> <sect1 id="security.current"> @@ -651,4 +856,7 @@ sgml-local-catalogs:nil sgml-local-ecat-files:nil End: +vim600: syn=xml fen fdm=syntax fdl=2 si +vim: et tw=78 syn=sgml +vi: ts=1 sw=1 --> Index: phpdoc/hu/chapters/config.xml diff -u phpdoc/hu/chapters/config.xml:1.15 phpdoc/hu/chapters/config.xml:1.16 --- phpdoc/hu/chapters/config.xml:1.15 Wed Dec 12 15:50:49 2001 +++ phpdoc/hu/chapters/config.xml Wed Dec 19 20:20:50 2001 @@ -1,5 +1,6 @@ <?xml version="1.0" encoding="iso-8859-2"?> -<!-- EN-Revision: 1.16 Maintainer: goba Status: ready --> +<!-- EN-Revision: 1.32 Maintainer: pgerzson Status: ready --> +<!-- CREDITS: goba --> <chapter id="configuration"> <title>Konfiguráció</title> @@ -15,8 +16,31 @@ elindul. A <acronym>CGI</acronym> verzióban ez minden meghíváskor megtörténik. </simpara> + <para> + <example> + <title>php.ini példa</title> + <programlisting role="ini"> +<![CDATA[ +; any text on a line after an unquoted semicolon (;) is ignored +[php] ; section markers (text within square brackets) are also ignored +; Boolean values can be set to either: +; true, on, yes +; or false, off, no, none +register_globals = off +magic_quotes_gpc = yes - <simpara> +; you can enclose strings in double-quotes +include_path = ".:/usr/local/lib/php" + +; backslashes are treated the same as any other character +include_path = ".;c:\php\lib" +]]> +</programlisting> +<!-- TODO: add more details about values and expressions --> + </example> + </para> + + <simpara> Ha a PHP-t Apache modulként használod, akkor a beállításokat az Apache konfigurációs fájljának direktíváival és .htaccess fájlokkal is @@ -84,6 +108,24 @@ </variablelist> </para> + <para> + <example> + <title>Apache konfigurációs példa</title> + <programlisting role="ini"> +<![CDATA[ +<IfModule mod_php4.c> + php_value include_path ".:/usr/local/lib/php" + php_flag safe_mode on +</IfModule> +<IfModule mod_php3.c> + php3_include_path ".:/usr/local/lib/php" + php3_safe_mode on +</IfModule> +]]> +</programlisting> + </example> + </para> + <simpara> A konfigurációs beállításokat lekérheted a <function>phpinfo</function>-val. Egyenkénti @@ -357,73 +399,99 @@ <type>string</type> </term> <listitem> - <para> - Beállítja a GET/POST/COOKIE sorrendet a változók létrehozásához. - Az alapbeállítású érték "GPC". Ha például ezt "GP"-re írod át, - a PHP figyelmen kívül fogja hagyni a cookie-kat, és ha van egy - POST és egy GET értéked ugyanazzal a névvel, a PHP a POST - értéket teszi be a név által megadott változóba. - </para> + <para> + Beállítja a GET/POST/COOKIE sorrendet a változók létrehozásához. + Az alapbeállítású érték "GPC". Ha például ezt "GP"-re írod át, + a PHP figyelmen kívül fogja hagyni a cookie-kat, és ha van egy + POST és egy GET értéked ugyanazzal a névvel, a PHP a POST + értéket teszi be a név által megadott változóba. + </para> + <para> + Ez az opció nem elérhetõ PHP 4-ben. + Használd helyette a <link linkend="ini.variables-order">variables_order</link>-t! + </para> + + </listitem> + </varlistentry> + + <varlistentry id="ini.variables-order"> + <term> + <parameter>variables_order</parameter> + <type>string</type> + </term> + <listitem> + <para> + Beállítja az ún. EGPCS (Environment - környezeti, GET, POST, Cookie, + Server) változók globális megfelelõinek létrehozási sorrendjét. + Az alapbeállítás az "EGPCS". Ha például "GP"-re van beállítva, + akkor emiatt a PHP figyelmen kívül hagyja a környezeti és szerver + változókat valamint a cookie-kat (sütiket), és minden GET-ben kapott + változót felülír a POST metódussal elküldött, azonos nevû változó. + </para> + <para> + Lásd még: <link linkend="ini.register-globals">register_globals</link>! + </para> </listitem> </varlistentry> <varlistentry id="ini.ignore-user-abort"> <term> - <parameter>ignore_user_abort</parameter> - <type>string</type> + <parameter>ignore_user_abort</parameter> + <type>string</type> </term> <listitem> - <para> - Alapbeállításban "On". Ha kikapcsolod, a szkriptek leállnak, amikor - megpróbálnak küldeni a kliensnek valamit, miután a kliens lezárta - a kapcsolat. - <function>ignore_user_abort</function>. - </para> + <para> + Alapbeállításban "On". Ha kikapcsolod, a szkriptek leállnak, amikor + megpróbálnak küldeni a kliensnek valamit, miután a kliens lezárta + a kapcsolat. + <function>ignore_user_abort</function>. + </para> </listitem> </varlistentry> <varlistentry id="ini.include-path"> <term> - <parameter>include_path</parameter> - <type>string</type> + <parameter>include_path</parameter> + <type>string</type> </term> <listitem> - <para> - Egy könyvtárlistát határoz meg, ahol a - <function>require</function>, <function>include</function> - és <function>fopen_with_path</function> függvények a fájlokat - keresik. A formátum a rendszer <envar>PATH</envar> - környezeti változójának formátumával egyezõ: egy könyvtárlista kettõspontokkal - elválasztva UNIX alatt, pontosvesszõvel Windows alatt. - <example> - <title>UNIX include_path</title> - <programlisting role="php3.ini"> + <para> + Egy könyvtárlistát határoz meg, ahol a + <function>require</function>, <function>include</function> + és <function>fopen_with_path</function> függvények a fájlokat + keresik. A formátum a rendszer <envar>PATH</envar> + környezeti változójának formátumával egyezõ: egy könyvtárlista kettõspontokkal + elválasztva UNIX alatt, pontosvesszõvel Windows alatt. + <example> + <title>UNIX include_path</title> + <programlisting role="php3.ini"> <![CDATA[ include_path=.:/home/httpd/php-lib ]]> -</programlisting> - </example> - <example> - <title>Windows include_path</title> - <programlisting role="php3.ini"> + </programlisting> + </example> + <example> + <title>Windows include_path</title> + <programlisting role="php3.ini"> <![CDATA[ include_path=".;c:\www\phplib" ]]> -</programlisting> - </example> - Alapbeállítású érték a <literal>.</literal> - (pont), azaz csak a szkript könyvtára.</para> + </programlisting> + </example> + Alapbeállítású érték a <literal>.</literal> + (pont), azaz csak a szkript könyvtára. + </para> </listitem> </varlistentry> <varlistentry id="ini.isapi-ext"> <term> - <parameter>isapi_ext</parameter> - <type>string</type> + <parameter>isapi_ext</parameter> + <type>string</type> </term> <listitem> - <para> - </para> + <para> + </para> </listitem> </varlistentry> @@ -559,7 +627,11 @@ <varname>$HTTP_SERVER_VARS</varname> asszociatív globális tömbökkel. </para> - </listitem> + <para> + Figyelj arra, hogy ahhoz ez mûködjön, az apache konfigurációs + fájljában a Directory blokkban az AllowOveride All beállítást kell megadni. + </para> + </listitem> </varlistentry> <varlistentry id="ini.short-open-tag"> @@ -630,11 +702,11 @@ <type>string</type> </term> <listitem> - <para> - Ebbe az ideiglenes könyvtárba fogja a PHP - elmenteni a weben feltöltött fájlokat. Írhatónak - kell lennie a felhasználó számára, ami alatt a PHP fut. - </para> + <para> + Ebbe az ideiglenes könyvtárba fogja a PHP + elmenteni a weben feltöltött fájlokat. Írhatónak + kell lennie a felhasználó számára, ami alatt a PHP fut. + </para> </listitem> </varlistentry> @@ -683,7 +755,7 @@ </para> </sect2> - <sect2 id="ini.sect.mail"> + <!--sect2 id="ini.sect.mail"> <title>Levelezés beállítási lehetõségei</title> <variablelist> @@ -734,7 +806,7 @@ </varlistentry> </variablelist> - </sect2> + </sect2 --> <sect2 id="ini.sect.safe-mode"> <title>Safe Mode beállítási lehetõségek</title> @@ -747,8 +819,9 @@ </term> <listitem> <para> - Ki/bekapcsolja a PHP "safe mode" funkcióját. Lásd még a - <link linkend="security">Biztonság címû fejezetet</link>. + Ki/bekapcsolja a PHP "safe mode" funkcióját. Lásd még a + <link linkend="security">Biztonság</link> és + <link linkend="features.safe-mode">Safe Mode</link> c. fejezeteket! </para> </listitem> </varlistentry> @@ -916,7 +989,39 @@ </para> </listitem> </varlistentry> + + <varlistentry id="ini.mysql.default-port"> + <term> + <parameter>mysql.default_port</parameter> + <type>string</type> + </term> + <listitem> + <para> + Ha nincs egyéb portszám megadva, akkor ezt használja + az adatbáziskiszolgálóhoz történõ csatlakozáskor. + Ha nincs alapérték megadva, akkor a portszámot a + <literal>MYSQL_TCP_PORT</literal> környezeti változó, + az <filename>/etc/services</filename> beli <literal>mysql-tcp</literal> + bejegyzés vagy a fordításkor megadott <literal>MYSQL_PORT</literal> + állandó adja - ebben a vizsgálati sorrendben. Win32 alatt csak a + <literal>MYSQL_PORT</literal> állandót használja. + </para> + </listitem> + </varlistentry> + <varlistentry id="ini.mysql.default-socket"> + <term> + <parameter>mysql.default_socket</parameter> + <type>string</type> + </term> + <listitem> + <para> + Az alapértelmezés szerinti socket nevet helyi adatbázis-kiszolgálóhoz + történõ kapcsolódás esetén használja, ha nincs más név megadva. + </para> + </listitem> + </varlistentry> + <varlistentry id="ini.mysql.max-persistent"> <term> <parameter>mysql.max_persistent</parameter> @@ -1070,9 +1175,12 @@ (lásd a SESAM kézikönyvet): <informalexample> <programlisting role="bs2000"> +<![CDATA[ CNF=B NAM=K -NOTYPE</programlisting> +NOTYPE +]]> + </programlisting> </informalexample> </para> </listitem> @@ -1653,4 +1761,7 @@ sgml-local-catalogs:nil sgml-local-ecat-files:nil End: +vim600: syn=xml fen fdm=syntax fdl=2 si +vim: et tw=78 syn=sgml +vi: ts=1 sw=1 -->
Index: phpdoc/hu/chapters/security.xml diff -u phpdoc/hu/chapters/security.xml:1.14 phpdoc/hu/chapters/security.xml:1.15 --- phpdoc/hu/chapters/security.xml:1.14 Wed Dec 12 15:50:54 2001 +++ phpdoc/hu/chapters/security.xml Wed Dec 19 20:20:50 2001 @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="iso-8859-2"?> -<!-- EN-Revision: 1.19 Maintainer: goba Status: ready --> +<!-- EN-Revision: 1.38 Maintainer: pgerzson Status: ready --> <chapter id="security"> <title>Biztonság</title> @@ -35,13 +35,63 @@ fejlesztõn múlik. </simpara> <simpara> - 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éhány általános tanács következik. + Ez a fejezet néhány biztonsági tanácsot tárgyal, a különbözõ + beállítási lehetõségeket és azokat a helyzeteket tárja fel, amelyekben + ezeket biztonsággal lehet használni. Utána néhány kódolási szempontot + vesz át a különbözõ szintû biztonságosság szempontjából </simpara> + <sect1 id="security.general"> + <title>Általános szempontok</title> + <simpara> + A teljesen biztonságos rendszer kialakítása tulajdonképpen lehetlenség, + ezért a biztonsági területen alkalmazott megközelítés a kockázat és a + használhatóság közti egyensúly megteremtése. Ha minden a felhasználó + által küldött adat két biometrikus érvényesítést (pl. retina- és + ujjlenyomatvizsgálatot) igényel, akkor igen magas szintû a rendszer + "felelõsségre vonhatósága" (accountability). Ez azonban azt jelentené, hogy + félórába telne kitölteni egy meglehetõsen összetett ûrlapot, ami arra + ösztökélné a felhasználókat, hogy valahogy megkerüljék ezt a védelmet. + </simpara> + <simpara> + A legjobb védelem gyakran a kevésbé alkalmatlankodó és nem feltûnõ, + hogy megfeleljen a követelményeknek anélkül, hogy megakadályozná a + felhasználókat a munkájuk elvégzésében vagy túlterhelné a program íróit + annak túlzott mérvû bonyolultsága. Valójában néhány biztonsági támadás + pusztán a kiaknázása az olyasfajta túlságosan is kiépített védelemnek, amely + hajlamos elerodálódni az idõvel. + </simpara> + <simpara> + Egy mondatot érdemes megjegyezni: A rendszer csakis annyira jól védett, + amennyire a leggyengébb láncszeme. Ha minden tranzakciót hevesen + naplóz idõ, hely és tranzakciótípus alapján is, de a felhasználó csak + egy egyszerû süti (cookie) alapján azonosítja, akkor a felhasználók + tranzakciónaplón belüli elõfordulásának érvényessége, megbízhatósága + igen gyenge. + </simpara> + <simpara> + Amikor tesztelsz, vedd figyelembe, hogy nem vagy képes minden lehetõséget + kipróbálni már a legegyszerûbb oldalak esetén sem. Az általad várt adatok + teljesen különbözõek és összefüggéstelenek azoktól, amelyeket egy zsémbelõdõ + alkalmazott képes elküldeni, vagy amelyeket egy szoftverkalóz (cracker) több + havi munkájával állít össze, vagy ami nem más, mint egy házimacska + billenytyûzeten hagyott "lábnyoma". Ezért a legjobb, ha a programot logikai + nézõpontból közelíted meg, hogy sikerüljön észrevenni, hol jöhetnek elõ nem + várt adatok és azok a továbbiakban hogyan módosulhatnak, tûnhetnek el vagy + erõsödhetnek fel a hatásuk. + </simpara> + <simpara> + Az Internet tele van olyan emberekkel, akik azzal akarnak maguknak nevet + szerezni, hogy feltörik az oldalaidat, tönkreteszik a programjaidat, nem + helyénvaló tartalommal töltik fel azokat, mellesleg egy - két izgalmas(?) + napot szerezve ezzel Neked. Nem számít, hogy kis vagy nagy webhelyrõl van szó, + elég indok a támadásra, hogy rá vagy kapcsolva a hálóra, és van egy szervered, + amelyhez csatlakozni lehet. Sok kódtörõ program nem foglalkozik a méretekkel, + egyszerûen csak nagy mennyiségû IP blokkokra vadászik áldozatokat keresve ezzel + magának. Próbálj meg nem egy lenni közülük! + </simpara> + </sect1> + <sect1 id="security.cgi-bin"> <title>CGI futtatható állományként telepített PHP</title> @@ -284,14 +334,15 @@ <simpara> Á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 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 fájlokat sem tudja írni, amit kellene, vagy nem tud - végrehajtani adatbázis lekéréseket. + fut, nem képes például akármilyen fájlok írására a user könyvtárakba. + Letilthatjuk számára egy adatbázis elérését vagy megváltoztatását. + Tipikusan ebben a helyzetben már azokat a fájlokat sem tudja írni, + amit kellene, vagy egyaránt nem tud végrehajtani jó és rosszindulatú + adatbázis tranzakciókat. </simpara> <simpara> - Egy gyakori hiba ezen a ponton, hogy az Apache-nak root jogokat adnak. + Egy gyakori hiba ezen a ponton, hogy az Apache-nak root jogokat adnak vagy + valamilyen egyéb módon bõvítik az Apache jogait / lehetõségeit. </simpara> <simpara> Az Apache user jogainak root szintre bõvítése különösen @@ -299,6 +350,12 @@ chroot vagy más hasonló eszközök használata elkerülendõ, ha nem vagy biztonsági szakember. </simpara> + <simpara> + Van néhány egyszerûbb megoldás is. Az <link linkend="ini.open-basedir">open_basedir</link> + használatával szabályozni lehet, hogy mely könyvtárakat olvashatja a PHP. + Ki lehet jelölni ún. csak apache-s területeket, hogy minden web alapú mûveletet + ide ezekre a nem rendszer- és nem felhasználói fájlokra korlátozz. + </simpara> </sect1> <sect1 id="security.filesystem"> @@ -334,7 +391,7 @@ <![CDATA[ <?php // egy fájl törlése a user könyvtárából -$usernev = $user_altal_beadott_nev; +$usernev = $HTTP_POST_VARS["user_altal_beadott_nev"]; $konyvtar = "/home/$usernev"; $torlendo_file = "$userfile"; unlink ($konyvtar/$torlendo_file); @@ -388,8 +445,8 @@ <?php // egy fájl törlése akárhonnan, ahol a PHP usernek // joga van erre. -$usernev = $HTTP_REMOTE_USER; // ez a user azonosított neve - // (ha volt elõtte azonosítás) +$usernev = $HTTP_SERVER_VARS['REMOTE_USER']; // ez a user azonosított neve + // (ha volt elõtte azonosítás) $konyvtar = "/home/$usernev"; @@ -397,7 +454,7 @@ unlink ($konyvtar/$torlendo_file); $fp = fopen("/home/logging/filedelete.log","+a"); // törlés naplózása -$logstring = "$HTTP_REMOTE_USER $konyvtar $torlendo_file"; +$logstring = "$usernev $konyvtar $torlendo_file"; fputs ($fp, $logstring); fclose($fp); @@ -405,24 +462,31 @@ ?> ]]> </programlisting> - </example> - Esetleg egy jobban testreszabott ellenõrzést is készíthetsz: + </example> + Mindamellett, ez sem mentes a hiányosságoktól. Ha az általad használt + hitelesítési módszer (authentication) megengedi a felhasználóknak, hogy + saját login naplót vezessenek, akkor ha egyikük a "../etc/" -t választja + a rendszer védtelenné válik. Ebbõl kiindulva, egy jobban testreszabott + ellenõrzést is készíthetsz: <example> <title>Biztonságosabb fájlnév-ellenõrzés</title> <programlisting role="php"> -<![CDATA[ -<?php -$username = getenv("REMOTE_USER"); -$homedir = "/home/$username"; - -if (!ereg('^[^./][^/]*$', $userfile)) - die('rossz fájlnév'); //nem hajtjuk végre a törlést - -//etc... -?> -]]> + <![CDATA[ +<?php +$usernev = $HTTP_SERVER_VARS['REMOTE_USER']; // hitelesites +$homedir = "/home/$usernev"; $homedir = "/home/$usernev"; + +if (!ereg('^[^./][^/]*$', $userfile)) + die('rossz fájlnév'); // vége, nincs feldolgozás + +if (!ereg('^[^./][^/]*$', $usernev)) + die('rossz usernev'); // vége, nincs feldolgozás +//stb... +?> </programlisting> - </example> + </example> + </para> + <para> A használt operációs rendszertõl függõen széles a védeni kívánt fájlok skálája, beleértve az eszköz hivatkozásokat (/dev/ vagy COM1), konfigurációs fájlokat (/etc/ és az .ini fájlok), jól ismert @@ -434,15 +498,32 @@ <sect1 id="security.errors"> <title>Hibajelzés</title> - <simpara> + <para> + A PHP biztonsági kérdések felõl a hibajelzéseknek két oldaluk van. + Az egyik hasznos a védelem növelése szempontjából, a másik káros rá. + </para> + <para> 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. - </simpara> - <simpara> + a lehetséges gyenge pontokat. Ha például a támadó összeszedegett + elég információt az elõzõ ûrlap kitöltések alapján, akkor + megpróbálhatja a változókat felülírni vagy megváltoztatni õket: + <example> + <title>Változók elleni támadás egy HTML oldallal</title> + <programlisting role="php"> +<![CDATA[ +<form method="post" action="tamadas_celpontja?usernev=rosszize&jelszo=rosszize"> +<input type="hidden" name="usernev" value="rosszize"> +<input type="hidden" name="jelszo" value="rosszize"> +</form> +]]> + </programlisting> + </example> + </para> + <para> A PHP által visszaadott hibaüzenetek általában hasznosak 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. @@ -452,16 +533,35 @@ <function>highlight_file</function> függvényeket a fejlesztés során hibakeresésre is használja, de egy élesben lévõ webhelyen ez rejtett változókat, ellenõrizetlen kódokat, - és más veszélyes információkat fedhet fel. - </simpara> - <simpara> + és más veszélyes információkat fedhet fel. Kifejezetten veszélyes + ismert forrású beépített hibakezelõvel rendelkezõ kódok használata. + Ha a támadó rájön, milyen általános technikát használsz, akkor + megpróbálhatja a nyers erõre alapozva feltörni az oldalt a + különbözõ megszokott hibakeresõ (debugging) változók elküldésével: + <example> + <title>Szokványos hibakeresõ változók kihasználása</title> + <programlisting role="php"> +<![CDATA[ +<form method="post" action="tamadas_celpontja?errors=Y&showerrors=1"&debug=1"> +<input type="hidden" name="errors" value="Y"> +<input type="hidden" name="showerrors" value="1"> +<input type="hidden" name="debug" value="1"> +</form> +]]> + </programlisting> + </example> + </para> + <para> + A hibakezelés módjától függetlenül, az a lehetõség, hogy egy rendszerben + hibák után kuthatnak, odavezet, hogy a támadók is több információhoz + jutnak. Az általános hibaüzenetek nagyrészébõl például 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õ. - </simpara> - <simpara> + </para> + <para> Egy függvényhiba elárulhatja, hogy a rendszer milyen adatbázismotort használ, vagy hogy milyen programozói stílussal készült az adott weblap. Ez mélyebb kutatásokra @@ -471,15 +571,15 @@ állapítani, hogy milyen sorrendben végzed az azonosításokat (a hibák sorszámaiból). Ezzel a gyenge pontok is könnyen megtalálhatóak egy szkriptben. - </simpara> - <simpara> + </para> + <para> A fájlrendszer vagy általános PHP hibák jelezhetik, hogy milyen jogokkal rendelkezik a webszerver, és megmutathatják a fájlok elrendezését és struktúráját. A fejlesztõ által írt hibás kód súlyosbíthatja a helyzetet, régebben 'rejtett' információk könnyû kiderítését téve lehetõvé. - </simpara> - <simpara> + </para> + <para> 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 @@ -488,9 +588,111 @@ 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. - </simpara> + </para> + <para> + Hogy megelõzd a bajt, hasznát veheted a PHP saját + <function>error_reporting</function> függvényének, ami segít + biztonságosabbá tenni a programodat és megtalálni a változók + vészelyeket rejtõ használati formáit. A bevezetés elõtti tesztelés + során E_ALL beálllítással gyorsan meg lehet találni azokat a pontokat, + ahol a változóid könnyen és/vagy rosszindulatúan módosíthatók. Ha + már kész vagy a program bevezetésére, akkor a E_NONE-t használva + teljesen el tudod szigetelni a kódodat a további vizslatásoktól. + <example> + <title>Veszélyes változók felderítése az E_ALL segítségével</title> + <programlisting role="php"> +<![CDATA[ +<?php +if ($usernev) { // nincs inicializálva vagy ellenõrizve használat elõtt + $jo_belepes = 1; +} +if ($jo_belepes == 1) { // ha az elõzõ feltétel hamis, nincs inicializálva vagy ellenõrizve használat elõtt + fpassthru ("/nagyon/kenyes/adatok/index.html"); +} +?> +]]> + </programlisting> + </example> + </para> </sect1> - + + <sect1 id="security.registerglobals"> + <title>Globálisan is elérhetõ változók (Register Globals) használata</title> + <para> + A biztonság növelésére használható a PHP egyik lehetõsége: a + <link linkend="ini.register-globals">register_globals</link> = off beállítás + használata. Ennek a kikapcsolása azt jelenti, hogy nem "szennyezi" a PHP + kódot bármely felhasználótól jövõ változó, és így csökken a potenciális + támadó által befolyásolható változók köre. Még több idõt kell azzal tölteniük, + hogy kitalálják a változók feltöltésének módját, és a belsõ változóid + hatékonyan elkülönülnek a felhasználó által elküldött adatoktól. + </para> + <para> + While it does slightly increase the amount of effort required + to work with PHP, it has been argued that the benefits far + outweigh the effort. + <example> + <title>register_globals=off nélkül</title> + <programlisting role="php"> +<![CDATA[ +<?php +if ($usernev) { // felhasználható által hamisítható get/post/cookies + $jo_belepes = 1; +} + +if ($jo_belepes == 1) { // felhasználható által hamisítható get/post/cookies + fpassthru ("/nagyon/kenyes/adatok/index.html"); +} +?> +]]> + </programlisting> + </example> + <example> + <title>register_globals = off használatával</title> + <programlisting role="php"> +<![CDATA[ +<?php +if($HTTP_COOKIE_VARS['usernev']){ + // csak sütiként jöhet, hamisítva vagy épp ellenkezõleg + $jo_belepes = 1; + fpassthru ("/nagyon/kenyes/adatok/index.html"); +} +?> +]]> + </programlisting> + </example> + Okosan használva, még azt képes lehet jelezni, ha hamisítást + kíséreltek meg. Ha elõre tudod, hogy mely változóknak honnan + kell érkezniük, megvizsgálhatod, hogy vajon más módon nem próbálták-e + meg elküldeni ezt a változót. Ez nem garantálja, hogy az adatok + nem hamisíthatók, azonban megköveteli a támadótól, hogy az rátaláljon + a megfelelõ hamisítási módszerre. + <example> + <title>Egyszerû változó-átvétel felfedése</title> + <programlisting role="php"> +<![CDATA[ +<?php +if ($HTTP_COOKIE_VARS['usernev'] && + !$HTTP_POST_VARS['usernev'] && + !$HTTP_GET_VARS['usernev'] ) { + // egyéb usernev azonosítások elvégzése ... + $jo_belepes = 1; + fpassthru ("/nagyon/kenyes/adatok/index.html"); +} else { + mail("admin@example.com", "Lehetséges betörési kísérlet", $HTTP_SERVER_VARS['REMOTE_ADDR']); + echo "Védelmi szabályok megszegése, adminisztrátor értesítve."; + exit; +} +?> +]]> + </programlisting> + </example> + Természetesen register_globals egyszerû kikapcsolása nem jelenti azt, hogy + a kód biztonságos. Minden beérkezõ adatot valamilyen egyéb módon ellenõrizni + kell. + </para> + </sect1> + <sect1 id="security.variables"> <title>Felhasználótól érkezõ adatok</title> <para> @@ -508,7 +710,7 @@ // talán valaki máséból? unlink ($ordogi_valtozo); -// Az elérés naplózása... vagy nem? +// Az elérés naplózása... vagy egy /etc/passwd bejegyzésé? fputs ($fp, $ordogi_valtozo); // Valami egyértelmû dolog futtatása.. vagy rm -rf *? @@ -570,51 +772,54 @@ </para> </sect1> - <sect1 id="security.general"> - <title>Általános meggondolások</title> - <simpara> - 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. - </simpara> - <simpara> - Egy mondá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û sütivel azonosítod, keveset érsz a naplókkal. - </simpara> - <simpara> - Amikor kipróbálod a kódokat, 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. - </simpara> - <simpara> - 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 webhelyedet, értelmetlen adatokat - küldenek be, és más módokon teszik érdekessé a napodat. - Nem számít, hogy nagy vagy kis webhelyed van, célpont lehetsz, - mert online vagy, mivel van webkiszolgálód, 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. - </simpara> + <sect1 id="security.hiding"> + <title>PHP elrejtése</title> + <para> + Néhány egyszerû módszerrel elrejtheted azt, hogy PHP-t használsz, + így lassítva le a támadót, aki fel akarja deríteni a rendszered + gyenge pontjait. A php.ini-ben az expose_php = off beállítással + csökkentheted ezeket az információkat. + </para> + <para> + Másik taktika, hogy a webszervert (pl. apache) úgy állítod be + a .htaccess-en vagy az apache konfigurációs fájlában, hogy + különbözõ típusú fájlokat futtass a PHP-n keresztül. Más + félrevezetõ fájlkiterjesztéseket használhatsz: + <example> + <title>PHP elrejtése más nyelvként</title> + <programlisting role="apache-conf"> +<![CDATA[ +# úgy tûnik, mintha PHP helyett mást használnál +AddType application/x-httpd-php .asp .py .pl +]]> + </programlisting> + </example> + vagy teljesen ismeretlent is megadhatsz: + <example> + <title>ismeretlen típusok használata PHP fájlok kiterjesztéseként</title> + <programlisting role="apache-conf"> +<![CDATA[ +# PHP kódok teljesen ismeretlen típusúnak tûnnek +AddType application/x-httpd-php .bop .foo .133t +]]> + </programlisting> + </example> + vagy html kódként is elrejtheted, amely csekély teljesítménycsökkenést okoz, + mivel minden html oldal átmegy a PHP-n: + <example> + <title>html típus használata PHP fájlkiterjesztésként</title> + <programlisting role="apache-conf"> +<![CDATA[ +# PHP kódok html típusúnak tûnnek +AddType application/x-httpd-php .htm .html +]]> + </programlisting> + </example> + Ahhoz, hogy ez jól mûködjön, minden PHP fájlodat át kell nevezni + a fenti kiterjesztések valamelyikének megfelelõen. Mivel ez is az + elrejtõzésen / ismeretlenségen alapuló védelmi forma, kevés hátránya + mellett csekély megakadályozó intézkedést jelent. + </para> </sect1> <sect1 id="security.current"> @@ -651,4 +856,7 @@ sgml-local-catalogs:nil sgml-local-ecat-files:nil End: +vim600: syn=xml fen fdm=syntax fdl=2 si +vim: et tw=78 syn=sgml +vi: ts=1 sw=1 --> Index: phpdoc/hu/chapters/config.xml diff -u phpdoc/hu/chapters/config.xml:1.15 phpdoc/hu/chapters/config.xml:1.16 --- phpdoc/hu/chapters/config.xml:1.15 Wed Dec 12 15:50:49 2001 +++ phpdoc/hu/chapters/config.xml Wed Dec 19 20:20:50 2001 @@ -1,5 +1,6 @@ <?xml version="1.0" encoding="iso-8859-2"?> -<!-- EN-Revision: 1.16 Maintainer: goba Status: ready --> +<!-- EN-Revision: 1.32 Maintainer: pgerzson Status: ready --> +<!-- CREDITS: goba --> <chapter id="configuration"> <title>Konfiguráció</title> @@ -15,8 +16,31 @@ elindul. A <acronym>CGI</acronym> verzióban ez minden meghíváskor megtörténik. </simpara> + <para> + <example> + <title>php.ini példa</title> + <programlisting role="ini"> +<![CDATA[ +; any text on a line after an unquoted semicolon (;) is ignored +[php] ; section markers (text within square brackets) are also ignored +; Boolean values can be set to either: +; true, on, yes +; or false, off, no, none +register_globals = off +magic_quotes_gpc = yes - <simpara> +; you can enclose strings in double-quotes +include_path = ".:/usr/local/lib/php" + +; backslashes are treated the same as any other character +include_path = ".;c:\php\lib" +]]> +</programlisting> +<!-- TODO: add more details about values and expressions --> + </example> + </para> + + <simpara> Ha a PHP-t Apache modulként használod, akkor a beállításokat az Apache konfigurációs fájljának direktíváival és .htaccess fájlokkal is @@ -84,6 +108,24 @@ </variablelist> </para> + <para> + <example> + <title>Apache konfigurációs példa</title> + <programlisting role="ini"> +<![CDATA[ +<IfModule mod_php4.c> + php_value include_path ".:/usr/local/lib/php" + php_flag safe_mode on +</IfModule> +<IfModule mod_php3.c> + php3_include_path ".:/usr/local/lib/php" + php3_safe_mode on +</IfModule> +]]> +</programlisting> + </example> + </para> + <simpara> A konfigurációs beállításokat lekérheted a <function>phpinfo</function>-val. Egyenkénti @@ -357,73 +399,99 @@ <type>string</type> </term> <listitem> - <para> - Beállítja a GET/POST/COOKIE sorrendet a változók létrehozásához. - Az alapbeállítású érték "GPC". Ha például ezt "GP"-re írod át, - a PHP figyelmen kívül fogja hagyni a cookie-kat, és ha van egy - POST és egy GET értéked ugyanazzal a névvel, a PHP a POST - értéket teszi be a név által megadott változóba. - </para> + <para> + Beállítja a GET/POST/COOKIE sorrendet a változók létrehozásához. + Az alapbeállítású érték "GPC". Ha például ezt "GP"-re írod át, + a PHP figyelmen kívül fogja hagyni a cookie-kat, és ha van egy + POST és egy GET értéked ugyanazzal a névvel, a PHP a POST + értéket teszi be a név által megadott változóba. + </para> + <para> + Ez az opció nem elérhetõ PHP 4-ben. + Használd helyette a <link linkend="ini.variables-order">variables_order</link>-t! + </para> + + </listitem> + </varlistentry> + + <varlistentry id="ini.variables-order"> + <term> + <parameter>variables_order</parameter> + <type>string</type> + </term> + <listitem> + <para> + Beállítja az ún. EGPCS (Environment - környezeti, GET, POST, Cookie, + Server) változók globális megfelelõinek létrehozási sorrendjét. + Az alapbeállítás az "EGPCS". Ha például "GP"-re van beállítva, + akkor emiatt a PHP figyelmen kívül hagyja a környezeti és szerver + változókat valamint a cookie-kat (sütiket), és minden GET-ben kapott + változót felülír a POST metódussal elküldött, azonos nevû változó. + </para> + <para> + Lásd még: <link linkend="ini.register-globals">register_globals</link>! + </para> </listitem> </varlistentry> <varlistentry id="ini.ignore-user-abort"> <term> - <parameter>ignore_user_abort</parameter> - <type>string</type> + <parameter>ignore_user_abort</parameter> + <type>string</type> </term> <listitem> - <para> - Alapbeállításban "On". Ha kikapcsolod, a szkriptek leállnak, amikor - megpróbálnak küldeni a kliensnek valamit, miután a kliens lezárta - a kapcsolat. - <function>ignore_user_abort</function>. - </para> + <para> + Alapbeállításban "On". Ha kikapcsolod, a szkriptek leállnak, amikor + megpróbálnak küldeni a kliensnek valamit, miután a kliens lezárta + a kapcsolat. + <function>ignore_user_abort</function>. + </para> </listitem> </varlistentry> <varlistentry id="ini.include-path"> <term> - <parameter>include_path</parameter> - <type>string</type> + <parameter>include_path</parameter> + <type>string</type> </term> <listitem> - <para> - Egy könyvtárlistát határoz meg, ahol a - <function>require</function>, <function>include</function> - és <function>fopen_with_path</function> függvények a fájlokat - keresik. A formátum a rendszer <envar>PATH</envar> - környezeti változójának formátumával egyezõ: egy könyvtárlista kettõspontokkal - elválasztva UNIX alatt, pontosvesszõvel Windows alatt. - <example> - <title>UNIX include_path</title> - <programlisting role="php3.ini"> + <para> + Egy könyvtárlistát határoz meg, ahol a + <function>require</function>, <function>include</function> + és <function>fopen_with_path</function> függvények a fájlokat + keresik. A formátum a rendszer <envar>PATH</envar> + környezeti változójának formátumával egyezõ: egy könyvtárlista kettõspontokkal + elválasztva UNIX alatt, pontosvesszõvel Windows alatt. + <example> + <title>UNIX include_path</title> + <programlisting role="php3.ini"> <![CDATA[ include_path=.:/home/httpd/php-lib ]]> -</programlisting> - </example> - <example> - <title>Windows include_path</title> - <programlisting role="php3.ini"> + </programlisting> + </example> + <example> + <title>Windows include_path</title> + <programlisting role="php3.ini"> <![CDATA[ include_path=".;c:\www\phplib" ]]> -</programlisting> - </example> - Alapbeállítású érték a <literal>.</literal> - (pont), azaz csak a szkript könyvtára.</para> + </programlisting> + </example> + Alapbeállítású érték a <literal>.</literal> + (pont), azaz csak a szkript könyvtára. + </para> </listitem> </varlistentry> <varlistentry id="ini.isapi-ext"> <term> - <parameter>isapi_ext</parameter> - <type>string</type> + <parameter>isapi_ext</parameter> + <type>string</type> </term> <listitem> - <para> - </para> + <para> + </para> </listitem> </varlistentry> @@ -559,7 +627,11 @@ <varname>$HTTP_SERVER_VARS</varname> asszociatív globális tömbökkel. </para> - </listitem> + <para> + Figyelj arra, hogy ahhoz ez mûködjön, az apache konfigurációs + fájljában a Directory blokkban az AllowOveride All beállítást kell megadni. + </para> + </listitem> </varlistentry> <varlistentry id="ini.short-open-tag"> @@ -630,11 +702,11 @@ <type>string</type> </term> <listitem> - <para> - Ebbe az ideiglenes könyvtárba fogja a PHP - elmenteni a weben feltöltött fájlokat. Írhatónak - kell lennie a felhasználó számára, ami alatt a PHP fut. - </para> + <para> + Ebbe az ideiglenes könyvtárba fogja a PHP + elmenteni a weben feltöltött fájlokat. Írhatónak + kell lennie a felhasználó számára, ami alatt a PHP fut. + </para> </listitem> </varlistentry> @@ -683,7 +755,7 @@ </para> </sect2> - <sect2 id="ini.sect.mail"> + <!--sect2 id="ini.sect.mail"> <title>Levelezés beállítási lehetõségei</title> <variablelist> @@ -734,7 +806,7 @@ </varlistentry> </variablelist> - </sect2> + </sect2 --> <sect2 id="ini.sect.safe-mode"> <title>Safe Mode beállítási lehetõségek</title> @@ -747,8 +819,9 @@ </term> <listitem> <para> - Ki/bekapcsolja a PHP "safe mode" funkcióját. Lásd még a - <link linkend="security">Biztonság címû fejezetet</link>. + Ki/bekapcsolja a PHP "safe mode" funkcióját. Lásd még a + <link linkend="security">Biztonság</link> és + <link linkend="features.safe-mode">Safe Mode</link> c. fejezeteket! </para> </listitem> </varlistentry> @@ -916,7 +989,39 @@ </para> </listitem> </varlistentry> + + <varlistentry id="ini.mysql.default-port"> + <term> + <parameter>mysql.default_port</parameter> + <type>string</type> + </term> + <listitem> + <para> + Ha nincs egyéb portszám megadva, akkor ezt használja + az adatbáziskiszolgálóhoz történõ csatlakozáskor. + Ha nincs alapérték megadva, akkor a portszámot a + <literal>MYSQL_TCP_PORT</literal> környezeti változó, + az <filename>/etc/services</filename> beli <literal>mysql-tcp</literal> + bejegyzés vagy a fordításkor megadott <literal>MYSQL_PORT</literal> + állandó adja - ebben a vizsgálati sorrendben. Win32 alatt csak a + <literal>MYSQL_PORT</literal> állandót használja. + </para> + </listitem> + </varlistentry> + <varlistentry id="ini.mysql.default-socket"> + <term> + <parameter>mysql.default_socket</parameter> + <type>string</type> + </term> + <listitem> + <para> + Az alapértelmezés szerinti socket nevet helyi adatbázis-kiszolgálóhoz + történõ kapcsolódás esetén használja, ha nincs más név megadva. + </para> + </listitem> + </varlistentry> + <varlistentry id="ini.mysql.max-persistent"> <term> <parameter>mysql.max_persistent</parameter> @@ -1070,9 +1175,12 @@ (lásd a SESAM kézikönyvet): <informalexample> <programlisting role="bs2000"> +<![CDATA[ CNF=B NAM=K -NOTYPE</programlisting> +NOTYPE +]]> + </programlisting> </informalexample> </para> </listitem> @@ -1653,4 +1761,7 @@ sgml-local-catalogs:nil sgml-local-ecat-files:nil End: +vim600: syn=xml fen fdm=syntax fdl=2 si +vim: et tw=78 syn=sgml +vi: ts=1 sw=1 -->