goba Sat Jan 20 11:12:31 2001 EDT
Modified files:
/phpdoc/hu/chapters intro.xml security.xml
Log:
Getting actual...
Index: phpdoc/hu/chapters/intro.xml
diff -u phpdoc/hu/chapters/intro.xml:1.8 phpdoc/hu/chapters/intro.xml:1.9
--- phpdoc/hu/chapters/intro.xml:1.8 Sun Oct 29 08:26:17 2000
+++ phpdoc/hu/chapters/intro.xml Sat Jan 20 11:12:31 2001
@@ -1,5 +1,5 @@
<chapter id="introduction">
- <title>Az első PHP oldal</title>
+ <title>Bevezetés a PHP-be</title>
<sect1 id="intro-whatis">
<title>Mi az a PHP?</title>
@@ -32,21 +32,20 @@
</example>
</para>
<para>
- Vedd észre, hogy ez mennyire más, mint egy hagyományos
- CGI szkript, amit más nyelveken írtak, mint a Perl vagy a C.
- Ahelyett, hogy írnál egy programot sok paranccsal, hogy HTML
- kimenetet produkáljon, csak egy HTML fájlt kell készítened
+ Vedd észre, hogy ez mennyire más, egy mint más nyelven (például
+ Perl vagy a C) írt hagyományos CGI szkript. Ahelyett, hogy
+ írnál egy programot sok paranccsal, hogy HTML kimenetet
+ produkáljon, csak egy HTML fájlt kell készítened
egy kis beépített kóddal, hogy ezt megtehesd. A PHP
- kódok <link linkend="language.basic-syntax.phpmode">speciális
- kezdő és befejező tag-ekkel</link> rendelkeznek, és
+ kódok blokkjai <link linkend="language.basic-syntax.phpmode">speciális
+ kezdő és befejező HTML elemekkel</link> rendelkeznek, és
így biztosítják, hogy a "PHP módból" ki-be ugorhass.
</para>
<para>
- Az különbözteti meg a PHP-t például a kliens
- oldali JavaScript-től, hogy a kód a szerveren fut. Ha lenne egy
- ilyen oldalad, amit az első példában látsz,
- akkor ha böngészőben megnézed az eredményt,
- nem tudod megállapítani, hogy milyen kód
+ Az különbözteti meg a PHP-t például a kliens oldali JavaScript
+ nyelvtől, hogy a kód a kiszolgálón fut. Ha lenne egy ilyen
+ oldalad, amit az első példában látsz, akkor ha böngészőben
+ megnézed az eredményt, nem tudod megállapítani, hogy milyen kód
állíthatta azt elő. Ráadásul beállíthatod úgy a szervered,
hogy minden HTML fájlt dolgozzon fel PHP parancsokat keresve,
és akkor már tényleg nem lesz rá mód, hogy kitalálják, mit rejtegetsz.
@@ -57,21 +56,20 @@
<title>Mit tud a PHP?</title>
<para>
Röviden: a PHP mindent tud, amit egy CGI programmal meg tudsz
- csinálni, például kérdőív-adatok lekérése, dinamikus
- tartalomelőállítás, vagy cookie-kezelés.
+ csinálni, mint például kérdőív-adatok lekérése, dinamikus
+ tartalomelőállítás, vagy sütikezelés.
</para>
<para>
- Talán a legjobb és legfontosabb tulajdonsága a nyelvnek
- az adatbázisok széles körű támogatása.
- Egy adatbázisokat kezelő weblap készítése
- PHP segítségével hihetetlenül egyszerű.
+ Talán a legjobb és legfontosabb tulajdonsága a nyelvnek az
+ adatbázisok széles körű támogatása. Egy adatbázisokat kezelő
+ weblap készítése PHP segítségével hihetetlenül egyszerű.
A következő adatbázisok támogatottak jelenleg:
<blockquote>
<simplelist columns="3">
<member>Adabas D</member>
<member>dBase</member>
<member>Empress</member>
- <member>FilePro (csak olvasásra képes)</member>
+ <member>FilePro (csak olvasásra)</member>
<member>Hyperwave</member>
<member>IBM DB2</member>
<member>Informix</member>
@@ -113,47 +111,49 @@
<sect1 id="intro-history">
<title>A PHP rövid története</title>
<simpara>
- A PHP-t &link.rasmus; agyalta ki valamikor 1994 őszén. Az
- első kiadatlan verziókat a saját honlapján használta, hogy
- figyelemmel kísérje, kik látogatják az oldalait.
- Az első mások által is használt verzió
- 1995 elején látott napvilágot és "Personal Home
- Page Tools" néven volt ismert. Egy nagyon egyszerű feldolgozó
- programból állt, ami csak néhány speciális
- makrót értett meg, valamint tartalmazott számos eszközt,
- amiket akkoriban gyakran használtak a honlapokon (számláló,
- vendégkönyv és hasonlók). A feldolgozó program
- újraírása után 1995 közepén a "PHP/FI 2.
+ A PHP-t &link.rasmus; agyalta ki valamikor 1994 őszén. Az első
+ kiadatlan verziókat a saját honlapján használta, hogy figyelemmel
+ kísérje, kik látogatják az oldalait. Az első mások által is
+ használt változat 1995 elején látott napvilágot és "Personal
+ Home Page Tools" néven volt ismert. Egy nagyon egyszerű
+ feldolgozó programból állt, ami csak néhány speciális makrót
+ értett meg, valamint tartalmazott számos eszközt, amiket akkoriban
+ gyakran használtak a honlapokon (számláló, vendégkönyv és hasonlók).
+ A feldolgozó program újraírása után 1995 közepén a "PHP/FI 2.
verzió" nevet kapta. A FI Rasmus egy másik szoftveréből
- került bele, amit HTML form információk feldolgozására
- készített. Ötvözte a "Personal Home Page Tools" programját
- a "Form Interpreter"-el és mSQL támogatást adott hozzá.
- Így született a PHP/FI. A program bámulatos ütemben
- fejlődött, és az emberek elkezdték kódokkal
- segíteni a fejlesztést..
+ került bele, amit HTML űrlap információk feldolgozására készített.
+ Ötvözte a "Personal Home Page Tools" programját a
+ "Form Interpreter"-el és mSQL támogatást adott hozzá.
+ Így született a PHP/FI. A program bámulatos ütemben fejlődött,
+ és az emberek elkezdték kódokkal segíteni a fejlesztést.
</simpara>
<simpara>
Nehéz lenne pontos adatokat megadni, de a PHP/FI-t körülbelül
- 15.000 website-on használták 1996 végére
- világszerte. 1997 közepére ez a szám 50.000 fölé
- nőtt. 1997 közepe nagy változást jelentett a
- PHP fejlesztésében. Rasmus saját kis projectjéből
- egy sokkal jobban szervezett csapatmunka lett. A feldolgozó
- programot Zeev Suraski és Andi Gutmans teljesen újraírták, és ez
- alkotta a lelkét az új PHP 3-nak. Sok kódot sikerült
- átvenni a PHP/FI-ből, másokat pedig teljesen újra kellett
- írni.
+ 15.000 webhelyen használták 1996 végére világszerte. 1997
+ közepére ez a szám 50.000 fölé nőtt. 1997 közepe nagy
+ változást jelentett a PHP fejlesztésében. Rasmus saját kis
+ projektjéből egy sokkal jobban szervezett csapatmunka lett. A
+ feldolgozó programot Zeev Suraski és Andi Gutmans teljesen
+ újraírták, és ez alkotta a lelkét az új PHP 3-nak. Sok kódot
+ sikerült átvenni a PHP/FI-ből, másokat pedig teljesen újra
+ kellett írni.
</simpara>
<simpara>
+ A legfrissebb változat (a PHP 4) a <ulink
+ url="&url.zend;">Zend</ulink> Scripting Engine használatával
+ nagyobb teljesítményt nyújt, még több külső könyvtárat és
+ kiterjesztést támogat, és modulként képes futni minden
+ népszerű webkiszolgálón.
+ </simpara>
+ <simpara>
Most a PHP 3 és a PHP 4 számos üzleti termékkel együtt kerül
- forgalomba, úgymint a C2 StrongHold web szerver és a RedHat Linux.
+ forgalomba, mint például a Red Hat StrongHold web szerver.
A <ulink url="&url.netcraft;">NetCraft</ulink> adatai szerint (lásd
<ulink url="&url.netcraft-survey;">Netcraft Web Server
- Survey</ulink>) egy óvatos becsléssel a PHP-t több mint 3.300.000
- site-on használják szerte a világon! Talán ez a szám jobban
- érzékelhető, ha hozzáteszem, hogy ez több, mint amennyi site
- Netscape Enterprise szerveren fut az Interneten, és közel áll
- a Microsoft IIS szerverek számához, ami 3.8 millió.
+ Survey</ulink>) egy óvatos becsléssel a PHP-t több mint 5.100.000
+ webhelyen használják szerte a világon! Talán ez a szám jobban
+ érzékelhető, ha hozzáteszem, hogy ez valamelyest meghaladja
+ a Microsoft IIS szerverek számát, ami 5,03 millió.
</simpara>
<!--
<figure>
@@ -161,12 +161,6 @@
<graphic fileref="&url.php.stats;"/>
</figure>
-->
- <simpara>
- A legfrissebb verzió (PHP 4) a <ulink
- url="&url.zend;">Zend</ulink> Scripting Engine-t használja
- magasabb teljesítmény eléréséhez, és nem csak Apache
- szervereken képes modulként futni.
- </simpara>
</sect1>
</chapter>
Index: phpdoc/hu/chapters/security.xml
diff -u phpdoc/hu/chapters/security.xml:1.8 phpdoc/hu/chapters/security.xml:1.9
--- phpdoc/hu/chapters/security.xml:1.8 Fri Dec 22 10:00:24 2000
+++ phpdoc/hu/chapters/security.xml Sat Jan 20 11:12:31 2001
@@ -3,28 +3,30 @@
<simpara>
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ó
+ 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 ú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.
+ 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.
</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
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.
+ fel tudd használni, de egyben azt is jelenti, hogy ezek és a
+ webkiszolgáló beállításainak kombinációi kritikus helyzeteket
+ teremthetnek.
</simpara>
<simpara>
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
+ A PHP használható teljes szerver-alkalmazások készítésére,
+ egy shell felhasználó 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örnyezetet, milyen biztonságosan, nagyban a PHP
fejlesztőn múlik.
@@ -34,7 +36,7 @@
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.
+ érdekesek lehetnek. Végül néhány általános tanács következik.
</simpara>
<sect1 id="security.cgi">
@@ -82,27 +84,26 @@
<filename role="uri">/titkos/doc.html</filename> a
<acronym>CGI</acronym> program által megnyitásra és futtatásra kerülő
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:
+ Tipikusan néhány webkiszolgáló 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
<filename role="url">http://domain.nev/titkos/szkript.php</filename>
- a PHP interpreter számára. Ezzel a beállítással a szerver először
+ a PHP értelmező számára. Ezzel a beállítással a szerver először
ellenőrzi az elérési engedélyeket a <filename
role="uri">/titkos</filename> könyvtárra, és ezután állítja elő
az átirányító kérést a <filename
role="url">http://domain.nev/cgi-bin/php/titkos/szkript.php</filename>
- 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 <filename
- role="uri">/titkos/szkript.php</filename> fájlra, csak a
- <filename role="uri">/cgi-bin/php</filename> fájlra. Ilyen módon
- bárki, aki elérheti a <filename
- role="uri">/cgi-bin/php</filename> címet, egyben tetszőleges
- védett dokumentumot is elérhet.
+ 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 <filename role="uri">/titkos/szkript.php</filename>
+ fájlra, csak a <filename role="uri">/cgi-bin/php</filename> fájlra.
+ Ilyen módon bárki, aki elérheti a
+ <filename role="uri">/cgi-bin/php</filename> címet, egyben
+ tetszőleges védett dokumentumot is elérhet.
</simpara>
<simpara>
A PHP esetében az <link
linkend="install.configure.enable-force-cgi-redirect">--enable-force-cgi-redirect</link>
- fordítási opció, a <link
+ fordítási paraméter, a <link
linkend="ini.doc-root">doc_root</link> és <link
linkend="ini.user-dir">user_dir</link> konfigurációs lehetőségek
használhatóak ennek kivédésére, ha a szerver dokumentumainak
@@ -119,27 +120,28 @@
<simpara>
Ha a szerveren nincs olyan tartalom, ami jelszó vagy IP alapú
védelemmel van ellátva, nincs szükség ezekre a konfigurációs
- 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 <link
+ beállításokra. Ha a kiszolgáló nem engedélyezi az átirányításokat,
+ illetve ha nincs módja biztonságos átirányítással küldeni a kérést
+ a PHP számára, megadhatod az <link
linkend="install.configure.enable-force-cgi-redirect">--enable-force-cgi-redirect</link>
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
+ a PHP szkriptjeid nem függnek egy speciális szkript-hívási formától
sem, mint a <filename
role="php">http://domain.nev/cgi-bin/php/dir/szkript.php</filename>
vagy a <filename
role="php">http://domain.nev/dir/szkript.php</filename>.
</simpara>
<simpara>
- Az átirányítás beállítása Apache alatt az
- AddHandler és Action direktívákkal történik (lásd lentebb).
+ Az átirányítás beállítása Apache alatt az AddHandler és
+ Action direktívákkal történik (lásd lentebb).
</simpara>
</sect2>
<sect2 id="security.cgi.force-redirect">
<title>2. eset : az --enable-force-cgi-redirect használata</title>
<simpara>
- Ez a fordítási opció megakadályozza, hogy bárki meghívja a PHP-t egy <filename
+ Ez a fordítási paraméter megakadályozza, hogy bárki meghívja a
+ PHP-t egy <filename
role="php">http://domain.nev/cgi-bin/php/titkos/szkript.php</filename>.
URL-el. Ehelyett a PHP csak akkor fog elfogadni egy ilyen kérést
ha egy szerver átirányításban kapta.
@@ -157,10 +159,10 @@
Ez a lehetőség csak az Apache web szerverrel tesztelt és azon
múlik, hogy az Apache beállítja a nem standard
<envar>REDIRECT_STATUS</envar> CGI környezeti változót ha
- átirányított kérésről van szó.
- Ha a webszervered semmilyen módon nem közli, hogy ez egy direkt vagy
- átirányított kérés volt-e, nem használhatod ezt az opciót, így
- valamelyik másik módot kell használnod.
+ átirányított kérésről van szó. Ha a webkiszolgálód semmilyen
+ módon nem közli, hogy ez egy direkt vagy átirányított kérés
+ volt-e, nem használhatod ezt az opciót, így valamelyik
+ másik módot kell használnod.
</simpara>
</sect2>
@@ -172,7 +174,7 @@
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
+ pélsául 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 szkript kódja.
@@ -200,11 +202,11 @@
<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 kezdődő könyvtárban
- [<literal>~</literal>]).
- </simpara>
+ "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
+ kezdődő könyvtárban [<literal>~</literal>]).
+ </simpara>
<simpara>
Ha a user_dir meg van adva, például <filename
role="dir">public_php</filename>, akkor a fenti <filename
@@ -228,7 +230,7 @@
<title>4. eset : PHP feldolgozó a web könyvtárfán kívül</title>
<para>
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 <filename
+ weben látható könyvtárakon kívülre teszed. Például az <filename
role="dir">/usr/local/bin</filename> könyvtárba. Az egyetlen
igazi hátránya ennek az opciónak az, hogy minden PHP szkript
első sorának egy ehhez hasonló sort kell megadnod:
@@ -239,18 +241,19 @@
]]>
</programlisting>
</informalexample>
- ami megadja, hogy hol található a PHP feldolgozó, ami lefuttatja majd ezt
- a szkriptet. Ráadásul minden PHP szkriptednek futási jogot kell adni.
+ 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
- <literal>#!</literal> shell-escape mechanizmust használja sajátmaga futtatására.
+ <literal>#!</literal> shell-escape mechanizmust használja önmaga
+ futtatására.
</para>
<para>
Ahhoz, hogy ebben az esetben a PHP helyesen kezelje a
<envar>PATH_INFO</envar> és a <envar>PATH_TRANSLATED</envar>
információkat, a PHP feldolgozót az <link
linkend="install.configure.enable-discard-path">--enable-discard-path</link>
- "configure" opcióval kell fordítani.
+ "configure" paraméterrel kell fordítani.
</para>
</sect2>
@@ -260,17 +263,18 @@
<title>Apache modulként telepített PHP</title>
<simpara>
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). 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ú szkript elérheti, és módosíthatja az adatbázist,
+ felhasználói engedélyeket (tipikusan a "nobody" nevű
+ felhasználócal 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ú 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
+ védekezhetsz Apache azonosítási technikákkal, elkészítheted
+ a saját elérési modelledet LDAP segítségével, vagy készíthetsz
.htaccess fájlt, stb. és a PHP kódoddal együtt kezelheted
ezeket is.
</simpara>
@@ -308,13 +312,13 @@
<simpara>
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 fájlokat olvassa, pl. az /etc/password fájlt. Ez
+ rendszerfá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 a helyes fájlokat olvasod
illetve írod.
</simpara>
<simpara>
- Nézzük a következő szkriptet, ahol a user megadja, hogy
+ Nézzük a következő szkriptet, ahol a felhasználó 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
fájlkezelésre, ezért az Apache usernek engedélyezni kell
@@ -359,12 +363,12 @@
]]>
</programlisting>
</example>
- Két fontos komponens van, amit figyelembe kell venned, hogy
+ Két fontos komponens van, amire oda kell figyelned, hogy
megelőzd az ilyen problémákat:
<itemizedlist>
<listitem>
<simpara>
- Csak korlátozott jogok beállítása a PHP web usernek.
+ Csak korlátozott jogok beállítása a PHP usernek.
</simpara>
</listitem>
<listitem>
@@ -405,11 +409,11 @@
<programlisting role="php">
<![CDATA[
<?php
-$username = $HTTP_REMOTE_USER;
+$username = getenv("REMOTE_USER");
$homedir = "/home/$username";
if (!ereg('^[^./][^/]*$', $userfile))
- die('bad filename'); //die, do not process
+ die('rossz fájlnév'); //nem hajtjuk végre a törlést
//etc...
?>
@@ -439,10 +443,16 @@
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.
+ 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
+ <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>
- Például a hibaüzenetek nagyrészéből beazonosítható, hogy
+ 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
@@ -453,16 +463,18 @@
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.
+ tipikus hibák illetve 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
+ (a hibák sorszámaiból). Ezzel a gyenge pontok is könnyen
megtalálhatóak egy szkriptben.
</simpara>
<simpara>
A fájlrendszer vagy általános PHP hibák jelezhetik, hogy
- milyen jogokkal rendelkezik a webszerver, és megmutathatja
- a fájlok elrendezését és struktúráját.
+ 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>
Három megoldási lehetőség adódik erre a problémára. Az első,
@@ -513,7 +525,7 @@
</listitem>
<listitem>
<simpara>
- Előfordulhat azon a ponton, hogy szokatlan vagy nem kívánatos
+ Előfordulhat egy ponton, hogy szokatlan vagy nem kívánatos
adat jelenjen meg?
</simpara>
</listitem>
@@ -575,31 +587,47 @@
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ű cookie-val azonosítod, keveset érsz a a
- naplókkal.
+ egy egyszerű sütivel azonosítod, keveset érsz a naplókkal.
</simpara>
<simpara>
- 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
+ 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 site-odat, értelmetlen adatokat
+ működésképtelenné teszik a webhelyedet, é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
+ 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>
+
+ <sect1 id="security.current">
+ <title>Fontos aktuálisnak maradni</title>
+ <simpara>
+ A PHP, mint bármilyen más nagy rendszer állandóan változások és
+ fejlesztések alatt áll. Minden új változat kisebb-nagyobb
+ változtatásokat tartalmaz, feljesztve a nyelvet, kijavítva
+ biztonsági hibákat, beállítási kellemetlenségeket, és más
+ olyan elemeket, amik a teljes rendszer stabilitására és
+ biztonságára hatnak.
+ </simpara>
+ <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.
</simpara>
</sect1>
</chapter>
