pgerzson Mon Dec 24 18:21:33 2001 EDT
Modified files:
/phpdoc/hu/chapters security.xml
Log:
fix typos and an unclosed CDATA section
Index: phpdoc/hu/chapters/security.xml
diff -u phpdoc/hu/chapters/security.xml:1.18 phpdoc/hu/chapters/security.xml:1.19
--- phpdoc/hu/chapters/security.xml:1.18 Sat Dec 22 09:47:52 2001
+++ phpdoc/hu/chapters/security.xml Mon Dec 24 18:21:33 2001
@@ -7,20 +7,19 @@
<simpara>
A PHP egy igen hatékony nyelv és feldolgozó program, akár
- kiszolgálómodulként van jelen, akár egy különálló
- <acronym>CGI</acronym> 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 azonban ú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 kívánt
- kombinációját.
+ kiszolgálómodulként, akár egy különálló <acronym>CGI</acronym> 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 azonban ú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 megválasztásával, és megfelelő programírási
+ módszerek betartásával a szabadság és biztonság kívánt kombinációját
+ biztosítja számodra.
</simpara>
<simpara>
- Mivel sok különböző formája van a PHP használatának, számos
- konfigurációs lehetőség van a működésének beállítására. A
+ Mivel sokféleképpen és sok mindenre lehet a PHP használni, számos
+ konfigurációs lehetőség van a működésének szabályozására. A
lehetőségek nagy száma garantálja, hogy a PHP-t sokféle célra
fel tudd használni, de egyben azt is jelenti, hogy ezek és a
webkiszolgáló beállításainak kombinációi kritikus helyzeteket
@@ -36,62 +35,62 @@
fejlesztőn múlik.
</simpara>
<simpara>
- 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
+ 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>
+ <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ó
+ 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
+ "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
+ </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>
<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
+ amennyire a leggyengébb láncszeme. Ha minden tranzakciót lelkiismeretesen
+ naplóz idő, hely és tranzakciótípus alapján is, de a felhasználót csak
+ egy egyszerű süti (cookie) alapján azonosítja, akkor a felhasználók és a
+ naplózott tranzakciók közti összefüggések érvényessége, megbízhatósága
igen gyenge.
</simpara>
- <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
+ 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
+ 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(?)
+ </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>
+ </simpara>
+ </sect1>
<sect1 id="security.cgi-bin">
<title>CGI futtatható állományként telepített PHP</title>
@@ -190,7 +189,7 @@
Action direktívákkal történik (lásd lentebb).
</simpara>
</sect2>
-
+
<sect2 id="security.cgi-bin.force-redirect">
<title>2. eset : az --enable-force-cgi-redirect használata</title>
<simpara>
@@ -219,7 +218,7 @@
másik módot kell használnod.
</simpara>
</sect2>
-
+
<sect2 id="security.cgi-bin.doc-root">
<title>3. eset : a doc_root vagy user_dir beállítása</title>
<simpara>
@@ -241,8 +240,8 @@
<simpara>
A PHP szkript dokumentumok gyökérkönyvtárát a
<link linkend="ini.doc-root">doc_root</link> konfigurációs beállítással
- határozhatod meg a
- <link linkend="configuration.file">konfigurációs fájlban</link>, vagy a
+ határozhatod meg a
+ <link linkend="configuration.file">konfigurációs fájlban</link>, vagy a
<envar>PHP_DOCUMENT_ROOT</envar> környezeti változóban adhatod meg
ezt az értéket. Ha ez be van állítva a PHP CGI verziója a fájl
elérési útját a <parameter>doc_root</parameter> és a kérés elérési
@@ -252,13 +251,13 @@
</simpara>
<simpara>
Egy másik itt használható opció a <link
- linkend="ini.user-dir">user_dir</link>. Ha ez nincs megadva, csak a
+ linkend="ini.user-dir">user_dir</link>. Ha ez nincs megadva, csak a
<parameter>doc_root</parameter> szabályozza a megnyitható fájlok
körét. Ekkor egy <filename
role="url">http://domain.nev/~user/doc.php</filename> URL nem a
"user" nevű felhasználó home könyvtárában lévő fájlt
keresi, hanem a <filename role="uri">~user/doc.php</filename>
- fájlt keresi a doc_root alatt (igen, egy tilde karakterrel
+ fájlt keresi a doc_root alatt (igen, egy tilde karakterrel
kezdődő könyvtárban [<literal>~</literal>]).
</simpara>
<simpara>
@@ -279,7 +278,7 @@
külön is használhatod.
</simpara>
</sect2>
-
+
<sect2 id="security.cgi-bin.shell">
<title>4. eset : PHP feldolgozó a web könyvtárfán kívül</title>
<para>
@@ -298,7 +297,7 @@
ami meghatározza, hogy hol található a PHP feldolgozó, ami lefuttatja
majd ezt a kódot. 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
+ sh vagy bármilyen más nyelven írsz és a
<literal>#!</literal> shell-escape mechanizmust használja önmaga
futtatására.
</para>
@@ -310,7 +309,7 @@
"configure" paraméterrel kell fordítani.
</para>
</sect2>
-
+
</sect1>
<sect1 id="security.apache">
@@ -336,8 +335,8 @@
Á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 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,
+ 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>
@@ -351,12 +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>
+ <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>
+ </simpara>
</sect1>
<sect1 id="security.filesystem">
@@ -423,8 +422,8 @@
?>
]]>
</programlisting>
- </example>
- Két fontos komponens van, amire oda kell figyelned, hogy
+ </example>
+ Két fontos komponens van, amire oda kell figyelned, hogy
megelőzd az ilyen problémákat:
<itemizedlist>
<listitem>
@@ -446,7 +445,7 @@
<?php
// egy fájl törlése akárhonnan, ahol a PHP usernek
// joga van erre.
-$usernev = $HTTP_SERVER_VARS['REMOTE_USER']; // ez a user azonosított neve
+$usernev = $HTTP_SERVER_VARS['REMOTE_USER']; // ez a user azonosított neve
// (ha volt előtte azonosítás)
$konyvtar = "/home/$usernev";
@@ -464,45 +463,46 @@
]]>
</programlisting>
</example>
- Mindamellett, ez sem mentes a hiányosságoktól. Ha az általad használt
+ 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:
+ saját loginnevet válasszanak, és az egyikük a "../etc/" -t választja, akkor
+ a rendszer ugyanolyan 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
+ <![CDATA[
+<?php
$usernev = $HTTP_SERVER_VARS['REMOTE_USER']; // hitelesites
-$homedir = "/home/$usernev"; $homedir = "/home/$usernev";
+$homedir = "/home/$usernev"; $homedir = "/home/$usernev";
-if (!ereg('^[^./][^/]*$', $userfile))
+if (!ereg('^[^./][^/]*$', $userfile))
die('rossz fájlnév'); // vége, nincs feldolgozás
-if (!ereg('^[^./][^/]*$', $usernev))
+if (!ereg('^[^./][^/]*$', $usernev))
die('rossz usernev'); // vége, nincs feldolgozás
//stb...
-?>
+?>
+]]>
</programlisting>
</example>
- </para>
- <para>
+ </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
tárolóhelyek (/home/, My Documents), stb. Ezen okból könnyebb egy
olyan rendszert készíteni, ahol mindent megtiltasz azon kívül,
amit kifejezetten megengedsz.
- </para>
+ </para>
</sect1>
<sect1 id="security.errors">
<title>Hibajelzés</title>
- <para>
+ <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>
+ Az egyiket nézve 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
@@ -510,7 +510,7 @@
é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. Ha például a támadó összeszedegett
- elég információt az előző űrlap kitöltések alapján, akkor
+ 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>
@@ -522,22 +522,22 @@
</form>
]]>
</programlisting>
- </example>
+ </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.
Ez az összes információ, amit ki lehet nyerni. Nem ritka,
- hogy egy PHP fejlesztő a <function>show_source</function>,
- <function>highlight_string</function>, vagy
+ hogy egy PHP fejlesztő a <function>show_source</function>,
+ <function>highlight_string</function>, vagy
<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. 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
+ beépített hibakezelővel rendelkező ismert forrású 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>
@@ -550,12 +550,12 @@
</form>
]]>
</programlisting>
- </example>
+ </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.
+ 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
@@ -591,9 +591,9 @@
közül választhatsz.
</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
+ 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
@@ -605,7 +605,7 @@
<![CDATA[
<?php
if ($usernev) { // nincs inicializálva vagy ellenőrizve használat előtt
- $jo_belepes = 1;
+ $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");
@@ -616,29 +616,28 @@
</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
+ 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 a felhasználótól jövő változók
+ nem "szennyezik be" akaratlanul a PHP kódot, é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.
+ Az ezzel járó előnyök messze felülmúlják azt a kevés kényelmetlenséget, amelyet
+ a megnövekedett munka mennyisége okoz.
<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;
+ $jo_belepes = 1;
}
if ($jo_belepes == 1) { // felhasználható által hamisítható get/post/cookies
@@ -653,7 +652,7 @@
<programlisting role="php">
<![CDATA[
<?php
-if($HTTP_COOKIE_VARS['usernev']){
+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");
@@ -663,10 +662,10 @@
</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
+ 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>
@@ -675,7 +674,7 @@
<?php
if ($HTTP_COOKIE_VARS['usernev'] &&
!$HTTP_POST_VARS['usernev'] &&
- !$HTTP_GET_VARS['usernev'] ) {
+ !$HTTP_GET_VARS['usernev'] ) {
// egyéb usernev azonosítások elvégzése ...
$jo_belepes = 1;
fpassthru ("/nagyon/kenyes/adatok/index.html");
@@ -688,8 +687,8 @@
]]>
</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
+ 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>
@@ -745,7 +744,7 @@
Felhasználható-e más szkriptekkel együtt egy negatív
hatás elérésére?
</simpara>
- </listitem>
+ </listitem>
<listitem>
<simpara>
Megfelelően naplózásra kerülnek-e a tranzakciók
@@ -775,21 +774,21 @@
<sect1 id="security.hiding">
<title>A PHP elrejtése</title>
- <para>
- Általában a rejtegetésen és félrevezetésen alapuló védelem az egyik
+ <para>
+ Általában a rejtegetésen és félrevezetésen alapuló védelem az egyik
leggyengébb formája a védekezésnek, azonban néha minden apró többlet
kívánatos lehet.
- </para>
+ </para>
<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
+ 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
+ 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
+ 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>
@@ -841,7 +840,7 @@
<simpara>
Mint más rendszerszintű nyelvek és programok esetében, a legjobb
hozzáállás a gyakori frissítés, valamint a friss változatokról, és
- a fellépő változásokról való informálódás.
+ a fellépő változásokról való informálódás.
</simpara>
</sect1>
</chapter>
@@ -862,7 +861,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
+vim600: syn=xml fen fdm=syntax fdl=2 si
+vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->
