cvs: phpdoc-hu /security current.xml database.xml errors.xml globals.xml variables.xml
[email protected] ("Lajos Cseppent?")
| Newsgroups | php.doc.hu |
|---|---|
| Message-ID | <cvschappy1174229936@cvsserver> |
chappy Sun Mar 18 14:58:56 2007 UTC
Modified files:
/phpdoc-hu/security current.xml database.xml errors.xml globals.xml
variables.xml
Log:
updated
chappy-20070318145856.txt
(text/plain, 69.2 KB)
http://cvs.php.net/viewvc.cgi/phpdoc-hu/security/current.xml?r1=1.3&r2=1.4&diff_format=u
Index: phpdoc-hu/security/current.xml
diff -u phpdoc-hu/security/current.xml:1.3 phpdoc-hu/security/current.xml:1.4
--- phpdoc-hu/security/current.xml:1.3 Sun Aug 15 17:55:01 2004
+++ phpdoc-hu/security/current.xml Sun Mar 18 14:58:56 2007
@@ -1,24 +1,26 @@
<?xml version="1.0" encoding="iso-8859-2"?>
-<!-- EN-Revision: 1.2 Maintainer: bagilevi Status: ready -->
+<!-- EN-Revision: 1.3 Maintainer: bagilevi Status: ready -->
+<!-- CREDITS: chappy -->
+<!-- Reviewed: no -->
<!-- HU: Last EN-Revision before HU-split: 1.48 -->
<!-- EN: Last Revision before split: 1.66 -->
<!-- EN: splitted from ./index.xml, last change in rev 1.66 -->
- <chapter 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>
- </chapter>
+<chapter 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
+ bármilyen hibát, beállítási kellemetlenséget, és más
+ olyan elemet, ami a teljes rendszer stabilitására és
+ biztonságára hat.
+ </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>
+</chapter>
<!-- Keep this comment at the end of the file
http://cvs.php.net/viewvc.cgi/phpdoc-hu/security/database.xml?r1=1.7&r2=1.8&diff_format=u
Index: phpdoc-hu/security/database.xml
diff -u phpdoc-hu/security/database.xml:1.7 phpdoc-hu/security/database.xml:1.8
--- phpdoc-hu/security/database.xml:1.7 Fri Mar 18 01:06:27 2005
+++ phpdoc-hu/security/database.xml Sun Mar 18 14:58:56 2007
@@ -1,138 +1,140 @@
<?xml version="1.0" encoding="iso-8859-2"?>
-<!-- EN-Revision: 1.11 Maintainer: bagilevi Status: ready -->
+<!-- EN-Revision: 1.12 Maintainer: bagilevi Status: ready -->
+<!-- CREDITS: chappy -->
+<!-- Reviewed: no -->
<!-- HU: Last EN-Revision before HU-split: 1.48 -->
<!-- EN: Last Revision before split: 1.66 -->
<!-- EN: splitted from ./index.xml, last change in rev 1.66 -->
- <chapter id="security.database">
- <title>Adatbázis biztonság</title>
+<chapter id="security.database">
+ <title>Adatbázis biztonság</title>
+ <simpara>
+ Mostanában, a dinamikus tartalmat szolgáltató web alkalmazások sarokkövének
+ számítanak az adatbázisok. Mivel nagyon kényes, titkos adatok tárolására
+ szolgálhatnak ezek az adatbázisok, erõsen megfontolandó, miképp védjük meg
+ ezeket.
+ </simpara>
+ <simpara>
+ Információk tárolásához vagy visszakereséséhez csatlakozni kell az
+ adatbázishoz, egy érvényes lekérdezést kell küldeni, az eredményt ki kell
+ olvasni, és le kell zárni a kapcsolatot.
+ Manapság ebben a párbeszédben a Structured Query Language (SQL) a
+ leggyakrabban használt lekérdezõnyelv. Figyeld meg, miként lehet <link
+ linkend="security.database.sql-injection">SQL lekérdezéseket megbabrálni</link>!
+ </simpara>
+ <simpara>
+ Mint látható, a PHP egymagában, magától nem képes megvédeni az adatbázist.
+ A következõ bekezdések célja, hogy betekintést adjanak az alapokba, hogyan kell
+ adatbázisokat elérni és módosítani egy PHP programon belül.
+ </simpara>
+ <simpara>
+ Tartsd észben a következõ egyszerû szabályt: tagoltan védekezni. Minél több
+ helyen minél többet teszel a biztonság növeléséért, annál kisebb a valószínûsége,
+ hogy a támadók sikerrel járjanak, és kiteregessék titkos adataidat, vagy
+ visszaéljenek velük. A jó adatbázis- és alkalmazástervezés mindig a legnagyobb
+ félelmek figyelembevételérõl ismerszik meg.
+ </simpara>
+
+ <sect1 id="security.database.design">
+ <title>Adatbázis-tervezés</title>
<simpara>
- Mostanában, a dinamikus tartalmat szolgáltató web alkalmazások sarokkövének
- számítanak az adatbázisok. Mivel nagyon kényes, titkos adatok tárolására
- szolgálhatnak ezek az adatbázisok, erõsen megfontolandó, miképp védjük meg
- ezeket.
+ Az elsõ lépés mindig az adatbázis létrehozása, hacsak nem egy kívülállóét
+ kell használni. Az adatbázis létrehozásakor az a tulajdonosáé lesz, azé,
+ aki lefuttatta az utasításokat. Általában csak a tulajdonos - esetleg az
+ ún. superuser - jogosult bármiféle az adatbázis elemeit érintõ mûveletre.
+ Annak érdekében, hogy más felhasználók is hozzáférjenek, jogokat kell
+ nekik biztosítani.
</simpara>
<simpara>
- Információk tárolásához vagy visszakereséséhez csatlakozni kell az
- adatbázishoz, egy érvényes lekérdezést kell küldeni, az eredményt ki kell
- olvasni, és le kell zárni a kapcsolatot.
- Manapság ebben a párbeszédben a Structured Query Language (SQL) a
- leggyakrabban használt lekérdezõnyelv. Figyeld meg, miként lehet <link
- linkend="security.database.sql-injection">SQL lekérdezéseket megbabrálni</link>!
+ Az alkalmazásoknak soha nem szabad a tulajdonosaként vagy superuserként
+ csatlakozni az adatbázishoz, mert ezek bármilyen utasítást és lekérdezést
+ tetszés szerint futtathatnak, pl. a szerkezeti módosítást (táblák
+ megszüntetése) vagy táblák komplett törlése.
</simpara>
<simpara>
- Mint látható, a PHP egymagában, magától nem képes megvédeni az adatbázist.
- A következõ bekezdések célja, hogy betekintést adjanak az alapokba, hogyan kell
- adatbázisokat elérni és módosítani egy PHP programon belül.
+ Létre lehet hozni különbözõ, szigorúan korlátozott jogosultásgú adatbázis-
+ felhasználókat, melyek mindegyike az adatbázis manipulációnak egy-egy
+ különbözõ nézõpontjáért felelõsek. Mindig csak a legszükségesebb jogokat
+ szabad engedélyezni, és el kell kerülni, hogy ugyanazt a felhasználót
+ használjuk szerepeiben egymástól különbözõ esetekben. Ez azt jelenti, hogy
+ ha a behatoló meg is szerzi valamelyik ilyen minõsítést (hitelesítési
+ információt = felhasználói név + jelszó), akkor is csak akkora változást tud
+ okozni, mint az alkalmazás maga.
</simpara>
<simpara>
- Tartsd észben a következõ egyszerû szabályt: tagoltan védekezni. Minél több
- helyen minél többet teszel a biztonság növeléséért, annál kisebb a valószínûsége,
- hogy a támadók sikerrel járjanak, és kiteregessék titkos adataidat, vagy
- visszaéljenek velük. A jó adatbázis- és alkalmazástervezés mindig a legnagyobb
- félelmek figyelembevételérõl ismerszik meg.
+ Nem kell minden feladatfüggõ szabályozást a webalkalmazásban (PHP
+ szkriptben) kódolni, ehelyett inkább használd az adatbázis lehetõségeit:
+ view-k (nézetek), trigger-ek, rule-ok (szabályok). Ha a rendszer
+ fejlõdik, és más alkalmazásokat is csatlakoztatni kell az adatbázishoz,
+ akkor mindegyiknél újra kellene programozni ezeket a szabályokat.
+ Mindezen felül a triggerek arra is jók, hogy átlátszó módon és
+ automatikusan kezeljenek egyes mezõket az adatbázisban, amelyek gyakran
+ bepillantást adnak abba, hogy mi is történik/történt egy tranzakció közben,
+ vagy nagyon hasznosnak bizonyulhatnak hibakeresés során.
</simpara>
+ </sect1>
- <sect1 id="security.database.design">
- <title>Adatbázis-tervezés</title>
- <simpara>
- Az elsõ lépés mindig az adatbázis létrehozása, hacsak nem egy kívülállóét
- kell használni. Az adatbázis létrehozásakor az a tulajdonosáé lesz, azé,
- aki lefuttatta az utasításokat. Általában csak a tulajdonos - esetleg az
- ún. superuser - jogosult bármiféle az adatbázis elemeit érintõ mûveletre.
- Annak érdekében, hogy más felhasználók is hozzáférjenek, jogokat kell
- nekik biztosítani.
- </simpara>
- <simpara>
- Az alkalmazásoknak soha nem szabad a tulajdonosaként vagy superuserként
- csatlakozni az adatbázishoz, mert ezek bármilyen utasítást és lekérdezést
- tetszés szerint futtathatnak, pl. a szerkezeti módosítást (táblák
- megszüntetése) vagy táblák komplett törlése.
- </simpara>
- <simpara>
- Létre lehet hozni különbözõ, szigorúan korlátozott jogosultásgú adatbázis-
- felhasználókat, melyek mindegyike az adatbázis manipulációnak egy-egy
- különbözõ nézõpontjáért felelõsek. Mindig csak a legszükségesebb jogokat
- szabad engedélyezni, és el kell kerülni, hogy ugyanazt a felhasználót
- használjuk szerepeiben egymástól különbözõ esetekben. Ez azt jelenti, hogy
- ha a behatoló meg is szerzi valamelyik ilyen minõsítést (hitelesítési
- információt = felhasználói név + jelszó), akkor is csak akkora változást tud
- okozni, mint az alkalmazás maga.
- </simpara>
- <simpara>
- Nem kell minden feladatfüggõ szabályozást a webalkalmazásban (PHP
- szkriptben) kódolni, ehelyett inkább használd az adatbázis lehetõségeit:
- view-k (nézetek), trigger-ek, rule-ok (szabályok). Ha a rendszer
- fejlõdik, és más alkalmazásokat is csatlakoztatni kell az adatbázishoz,
- akkor mindegyiknél újra kellene programozni ezeket a szabályokat.
- Mindezen felül a triggerek arra is jók, hogy átlátszó módon és
- automatikusan kezeljenek egyes mezõket az adatbázisban, amelyek gyakran
- bepillantást adnak abba, hogy mi is történik/történt egy tranzakció közben,
- vagy nagyon hasznosnak bizonyulhatnak hibakeresés során.
- </simpara>
- </sect1>
-
- <sect1 id="security.database.connection">
- <title>Kapcsolódás az adatbázishoz</title>
- <simpara>
- Elképzelhetõ, hogy SSL-n keresztül szeretnél kapcsolódni az adatbázishoz,
- hogy a kiszolgáló és ügyfél közti teljes kommunikáció titkosításával
- növeld a védelmet. Használhatsz ssh-t is erre a célra. Akármelyik is
- áll, nagyon nehéz lesz a forgalom lehallgatásából információkat kinyerni
- ezek után.
- </simpara>
- <!--simpara>
- If your database server native SSL support, consider to use <link
- linkend="ref.openssl">OpenSSL functions</link> in communication between
- PHP and database via SSL.
- </simpara-->
- </sect1>
-
- <sect1 id="security.database.storage">
- <title>Titkosított tárolás</title>
- <simpara>
- SSL/SSH az ügyfél és kiszolgáló közt mozgó adatokat védi, és nem védi
- az adatbázisban tárolt megmaradó adatokat. Az SSL - kapcsolati protokoll.
- </simpara>
- <simpara>
- Mihelyst a támadó közvetlen hozzáférést szerzett az adatbázishoz -
- megkerülve a webszervert -, a tárolt adatok védtelenné váltak, és
- visszaélhet velük, ha csak maga az adatbázis nem védi valahogy azokat.
- Az adatok titkosítása kellõképp enyhíti ezt a veszélyt, de jelenleg
- nagyon kevés adatbázis kezelõ támogatja a titkosítást.
- </simpara>
- <simpara>
- Ez a legkönnyebben saját titkosító csomag írásával oldható meg, amelyet
- utána a PHP szkriptbõl el lehet érni. Ebben az esetben a PHP segítséget
- nyújthat néhány kiterjesztésével, mint például az <link
- linkend="ref.mcrypt">Mcrypt</link> vagy az <link
- linkend="ref.mhash">Mhash</link>, amelyek nagyon sokféle titkosító
- algoritmust fednek le. A szkript az adatbázisban való tárolás elõtt
- titkosítja a tárolni kívánt adatot, majd visszakereséskor
- visszafejti azokat. Nézd meg a hivatkozott
- fejezeteket további példákért, hogyan kell a titkosítást végrehajtani.
- </simpara>
- <simpara>
- Olyan teljesen rejtett adatok esetén, amelyeknek nyílt ábrázolásukra nincs
- szükség, mert nem lesznek kiíratva, a hashelés alkalmazása is
- meggondolandó. A hashelés jól ismert példája az, hogy a jelszavak helyett,
- azoknak csak MD5 hash értékét tárolják az adatbzisban. Lásd még:
- <function>crypt</function> és <function>md5</function>!
- </simpara>
- <example>
- <title>Hashelt jelszó mezõ használata</title>
- <programlisting role="php">
+ <sect1 id="security.database.connection">
+ <title>Kapcsolódás az adatbázishoz</title>
+ <simpara>
+ Elképzelhetõ, hogy SSL-n keresztül szeretnél kapcsolódni az adatbázishoz,
+ hogy a kiszolgáló és ügyfél közti teljes kommunikáció titkosításával
+ növeld a védelmet. Használhatsz ssh-t is erre a célra. Akármelyik is
+ áll, nagyon nehéz lesz a forgalom lehallgatásából információkat kinyerni
+ ezek után.
+ </simpara>
+ <!--simpara>
+ If your database server native SSL support, consider to use <link
+ linkend="ref.openssl">OpenSSL functions</link> in communication between
+ PHP and database via SSL.
+ </simpara-->
+ </sect1>
+
+ <sect1 id="security.database.storage">
+ <title>Titkosított tárolás</title>
+ <simpara>
+ SSL/SSH az ügyfél és kiszolgáló közt mozgó adatokat védi, és nem védi
+ az adatbázisban tárolt megmaradó adatokat. Az SSL - kapcsolati protokoll.
+ </simpara>
+ <simpara>
+ Mihelyst a támadó közvetlen hozzáférést szerzett az adatbázishoz -
+ megkerülve a webszervert -, a tárolt adatok védtelenné váltak, és
+ visszaélhet velük, ha csak maga az adatbázis nem védi valahogy azokat.
+ Az adatok titkosítása kellõképp enyhíti ezt a veszélyt, de jelenleg
+ nagyon kevés adatbázis kezelõ támogatja a titkosítást.
+ </simpara>
+ <simpara>
+ Ez a legkönnyebben saját titkosító csomag írásával oldható meg, amelyet
+ utána a PHP szkriptbõl el lehet érni. Ebben az esetben a PHP segítséget
+ nyújthat néhány kiterjesztésével, mint például az <link
+ linkend="ref.mcrypt">Mcrypt</link> vagy az <link
+ linkend="ref.mhash">Mhash</link>, amelyek nagyon sokféle titkosító
+ algoritmust fednek le. A szkript az adatbázisban való tárolás elõtt
+ titkosítja a tárolni kívánt adatot, majd visszakereséskor
+ visszafejti azokat. Nézd meg a hivatkozott
+ fejezeteket további példákért, hogyan kell a titkosítást végrehajtani.
+ </simpara>
+ <simpara>
+ Olyan teljesen rejtett adatok esetén, amelyeknek nyílt ábrázolásukra nincs
+ szükség, mert nem lesznek kiíratva, a hashelés alkalmazása is
+ meggondolandó. A hashelés jól ismert példája az, hogy a jelszavak helyett,
+ azoknak csak MD5 hash értékét tárolják az adatbzisban. Lásd még:
+ <function>crypt</function> és <function>md5</function>!
+ </simpara>
+ <example>
+ <title>Hashelt jelszó mezõ használata</title>
+ <programlisting role="php">
<![CDATA[
<?php
// jelszó hash értékének tárolása
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
- addslashes($username), md5($password));
+ pg_escape_string($username), md5($password));
$result = pg_query($connection, $query);
// lekérdezés, vajon a felhasználó a helyes jelszót adta-e meg
$query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
- addslashes($username), md5($password));
+ ph_escape_string($username), md5($password));
$result = pg_query($connection, $query);
if (pg_num_rows($result) > 0) {
@@ -143,40 +145,40 @@
?>
]]>
- </programlisting>
- </example>
- </sect1>
-
- <sect1 id="security.database.sql-injection">
- <title>SQL "beoltás"</title>
- <simpara>
- Sok web fejlesztõ nincs tudatában annak, hogy hogyan lehet megbabrálni
- az SQL utasításokat, ezért az SQL utasításokat megbízható parancsoknak
- feltételezik. Ez azt jelenti, hogy az SQL lekérdezésekkel ki lehet
- játszani a hozzáférés szabályozásokat, meg lehet kerülni a szabályos
- engedélyezési folyamatokat , és néha az SQL lekérdezésekkel a gazdagépen
- operációs rendszer szintû hozzáférést is lehet létrehozni.
- </simpara>
- <simpara>
- A "közvetlen SQL utasítás befecskendezés" olyan módszer, amellyel a támadó
- a régi SQL utasításokat módosítja vagy újakat ad hozzájuk annak érdekében,
- hogy titkos információkhoz jusson hozzá, vagy felülírja azokat, vagy veszélyes
- rendszer szintû parancsokat futtasson az adatbázis gazdagépén. Ez olyan
- alkalmazások esetén tehetõ meg, amelyek a felhasználótól származó adatokból
- és statikus paraméterekbõl állítanak össze SQL lekérdezéseket. Sajnos, a
- következõ példák mind megtörtént eseteken alapulnak.
- </simpara>
- <para>
- Az, hogy az adatbázishoz superuserként (olyan személyként, aki superusert
- képes létrehozni) csatlakozott az alkalmazás, és a bevitt adatok ellenõrzésének
- hiánya odavezethet, hogy a támadó superuser hozzáférést hozhat létre az
- adatbázishoz.
- <example>
- <title>
- A keresési eredmények lapokra tördelése ... és superuserek létrehozása
- (PostgreSQL)
- </title>
- <programlisting role="php">
+ </programlisting>
+ </example>
+ </sect1>
+
+ <sect1 id="security.database.sql-injection">
+ <title>SQL "beoltás"</title>
+ <simpara>
+ Sok web fejlesztõ nincs tudatában annak, hogy hogyan lehet megbabrálni
+ az SQL utasításokat, ezért az SQL utasításokat megbízható parancsoknak
+ feltételezik. Ez azt jelenti, hogy az SQL lekérdezésekkel ki lehet
+ játszani a hozzáférés szabályozásokat, meg lehet kerülni a szabályos
+ engedélyezési folyamatokat , és néha az SQL lekérdezésekkel a gazdagépen
+ operációs rendszer szintû hozzáférést is lehet létrehozni.
+ </simpara>
+ <simpara>
+ A "közvetlen SQL utasítás befecskendezés" olyan módszer, amellyel a támadó
+ a régi SQL utasításokat módosítja vagy újakat ad hozzájuk annak érdekében,
+ hogy titkos információkhoz jusson hozzá, vagy felülírja azokat, vagy veszélyes
+ rendszer szintû parancsokat futtasson az adatbázis gazdagépén. Ez olyan
+ alkalmazások esetén tehetõ meg, amelyek a felhasználótól származó adatokból
+ és statikus paraméterekbõl állítanak össze SQL lekérdezéseket. Sajnos, a
+ következõ példák mind megtörtént eseteken alapulnak.
+ </simpara>
+ <para>
+ Az, hogy az adatbázishoz superuserként (olyan személyként, aki superusert
+ képes létrehozni) csatlakozott az alkalmazás, és a bevitt adatok ellenõrzésének
+ hiánya odavezethet, hogy a támadó superuser hozzáférést hozhat létre az
+ adatbázishoz.
+ <example>
+ <title>
+ A keresési eredmények lapokra tördelése ... és superuserek létrehozása
+ (PostgreSQL)
+ </title>
+ <programlisting role="php">
<![CDATA[
<?php
@@ -185,15 +187,15 @@
$result = pg_query($conn, $query);
?>
]]>
- </programlisting>
- </example>
- A szokványos felhasználó az 'elõzõ', 'következõ' linkekre kattint, ahol
- az <varname>$offset</varname> az URL-be van kódolva. A szkript azt várja,
- hogy <varname>$offset</varname> decimális szám. Mégis, valaki megpróbálhatja
- a következõ utasítás <function>urlencode</function> alakját hozzáfûzni
- az URL-hez:
- <informalexample>
- <programlisting>
+ </programlisting>
+ </example>
+ A szokványos felhasználó az 'elõzõ', 'következõ' linkekre kattint, ahol
+ az <varname>$offset</varname> az URL-be van kódolva. A szkript azt várja,
+ hogy <varname>$offset</varname> decimális szám. Mégis, valaki megpróbálhatja
+ a következõ utasítás <function>urlencode</function> alakját hozzáfûzni
+ az URL-hez:
+ <informalexample>
+ <programlisting>
<![CDATA[
0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
@@ -201,36 +203,36 @@
from pg_shadow where usename='postgres';
--
]]>
- </programlisting>
- </informalexample>
- Ha ez megtörténne, akkor a szkript megajándékozná a támadót egy superuser
- hozzáféréssel. A <literal>0;</literal> arra való, hogy érvényes offset-et
- biztosítson az eredeti lekérdezésnek.
- </para>
- <note>
- <para>
- Általános módszer, hogy a <literal>--</literal> jellel kényszerítik ki,
- hogy az SQL elemzõ figyelmen kívül hagyja a lekérdezésként átadott
- string fennmaradó részét, mivel ez a megjegyzés szabványos jelölése
- SQL-ben.
- </para>
- </note>
- <para>
- Egy lehetséges módja a jelszavak megszerzésének, hogy kijátszák a keresõ
- oldalak találati listájának lekérdezéseit. A támadónak mindössze annyit
- kell tennie, hogy végig próbálja melyik elküldött SQL lekérdezésben használt
- változó nincs megfelelõen lekezelve. Ezeket általában egy megelõzõ ûrlapon
- lehet beállítani, hogy testre szabjuk a <literal>SELECT</literal> utasítás
- <literal>WHERE, ORDER BY, LIMIT</literal> és <literal>OFFSET</literal>
- klauzuláit. Ha a használt adatbáziskezelõ támogatja a <literal>UNION</literal>
- szerkezetet, akkor a támadó esetleg hozzáfûzhet egy teljesen új lekérdezést
- a már meglevõhöz, hogy kilistázza valamelyik táblában tárolt jelszavakat.
- Titkosított tárolás erõsen ajánlott!
- <example>
- <title>
- Árucikkek listázása ... és néhány jelszóé (valamilyen adatbázis kezelõ)
- </title>
- <programlisting role="php">
+ </programlisting>
+ </informalexample>
+ Ha ez megtörténne, akkor a szkript megajándékozná a támadót egy superuser
+ hozzáféréssel. A <literal>0;</literal> arra való, hogy érvényes offset-et
+ biztosítson az eredeti lekérdezésnek.
+ </para>
+ <note>
+ <para>
+ Általános módszer, hogy a <literal>--</literal> jellel kényszerítik ki,
+ hogy az SQL elemzõ figyelmen kívül hagyja a lekérdezésként átadott
+ string fennmaradó részét, mivel ez a megjegyzés szabványos jelölése
+ SQL-ben.
+ </para>
+ </note>
+ <para>
+ Egy lehetséges módja a jelszavak megszerzésének, hogy kijátszák a keresõ
+ oldalak találati listájának lekérdezéseit. A támadónak mindössze annyit
+ kell tennie, hogy végig próbálja melyik elküldött SQL lekérdezésben használt
+ változó nincs megfelelõen lekezelve. Ezeket általában egy megelõzõ ûrlapon
+ lehet beállítani, hogy testre szabjuk a <literal>SELECT</literal> utasítás
+ <literal>WHERE, ORDER BY, LIMIT</literal> és <literal>OFFSET</literal>
+ klauzuláit. Ha a használt adatbáziskezelõ támogatja a <literal>UNION</literal>
+ szerkezetet, akkor a támadó esetleg hozzáfûzhet egy teljesen új lekérdezést
+ a már meglevõhöz, hogy kilistázza valamelyik táblában tárolt jelszavakat.
+ Titkosított tárolás erõsen ajánlott!
+ <example>
+ <title>
+ Árucikkek listázása ... és néhány jelszóé (valamilyen adatbázis kezelõ)
+ </title>
+ <programlisting role="php">
<![CDATA[
<?php
@@ -241,52 +243,52 @@
?>
]]>
- </programlisting>
- </example>
- A lekérdezés statikus része egy másik <literal>SELECT</literal> utasítással
- kombinálható, ami az összes jelszót kilistázza:
- <informalexample>
- <programlisting>
+ </programlisting>
+ </example>
+ A lekérdezés statikus része egy másik <literal>SELECT</literal> utasítással
+ kombinálható, ami az összes jelszót kilistázza:
+ <informalexample>
+ <programlisting>
<![CDATA[
'
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
--
]]>
- </programlisting>
- </informalexample>
- Ha ezt a lekérdezést (a <literal>'</literal> és <literal>--</literal>
- megfelelõ használatával) valamelyik <varname>$query</varname>-ben használt
- változóhoz sikerülne hozzárendelni, akkor a szörny felébredne.
- </para>
- <para>
- SQL UPDATE parancsok ugyancsak ki vannak téve az adatbázisok elleni
- támadásoknak. Ezeket az utasításokat is fenyegetik az elõzõekben megismert
- megrövidítõ és hozzáfûzõ technikák. Ám emellett a támadó meghamisíthatja a
- <literal>SET</literal> klauzulát is. Ebben az esetben némi séma
- információval rendelkeznie kell a támadónak, hogy sikerrel járjon. Ezeket
- az információkat az ûrlapváltozók neveibõl szerezhetik meg, vagy egyszerûen
- próbálgatással. Az általánosan használt elnevezések a felhasználói névre és
- jelszóra nem nagyon különböznek egymástól.
- <example>
- <title>
- Jelszó átírásától ... új jogok megszerzéséig (valamilyen adatbázis kezelõ)
- </title>
- <programlisting role="php">
+ </programlisting>
+ </informalexample>
+ Ha ezt a lekérdezést (a <literal>'</literal> és <literal>--</literal>
+ megfelelõ használatával) valamelyik <varname>$query</varname>-ben használt
+ változóhoz sikerülne hozzárendelni, akkor a szörny felébredne.
+ </para>
+ <para>
+ SQL UPDATE parancsok ugyancsak ki vannak téve az adatbázisok elleni
+ támadásoknak. Ezeket az utasításokat is fenyegetik az elõzõekben megismert
+ megrövidítõ és hozzáfûzõ technikák. Ám emellett a támadó meghamisíthatja a
+ <literal>SET</literal> klauzulát is. Ebben az esetben némi séma
+ információval rendelkeznie kell a támadónak, hogy sikerrel járjon. Ezeket
+ az információkat az ûrlapváltozók neveibõl szerezhetik meg, vagy egyszerûen
+ próbálgatással. Az általánosan használt elnevezések a felhasználói névre és
+ jelszóra nem nagyon különböznek egymástól.
+ <example>
+ <title>
+ Jelszó átírásától ... új jogok megszerzéséig (valamilyen adatbázis kezelõ)
+ </title>
+ <programlisting role="php">
<![CDATA[
<?php
$query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
?>
]]>
- </programlisting>
- </example>
- A rosszindulatú felhasználó a <literal>' or uid like'%admin%'; --</literal>
- értéket adja át a <varname>$uid</varname> változónak, és ezzel
- megváltoztatja az adminisztrátor jelszavát, vagy egyszerûen a
- <varname>$pwd</varname>-nek a <literal>"hehehe', admin='yes', trusted=100 "</literal>
- (lezáró szóközzel) értéket adva még több jogot szerez magának. Ezt az
- SQL parancsot ezek így ferdítik el:
- <informalexample>
- <programlisting role="php">
+ </programlisting>
+ </example>
+ A rosszindulatú felhasználó a <literal>' or uid like'%admin%'; --</literal>
+ értéket adja át a <varname>$uid</varname> változónak, és ezzel
+ megváltoztatja az adminisztrátor jelszavát, vagy egyszerûen a
+ <varname>$pwd</varname>-nek a <literal>"hehehe', admin='yes', trusted=100 "</literal>
+ (lezáró szóközzel) értéket adva még több jogot szerez magának. Ezt az
+ SQL parancsot ezek így ferdítik el:
+ <informalexample>
+ <programlisting role="php">
<![CDATA[
// $uid == "' or uid like'%admin%'; --"
$query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --';";
@@ -294,15 +296,15 @@
// $pwd == "hehehe', admin='yes', trusted=100 "
$query = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...";
]]>
- </programlisting>
- </informalexample>
- </para>
- <para>
- Egy ijesztõ példa, hogyan lehet az adatbázis gazdagépén operációs
- rendszerszintû parancsokat futtatni.
- <example>
- <title>Az adatbázis-gazdagép operációs rendszere elleni támadás (MSSQL Server)</title>
- <programlisting role="php">
+ </programlisting>
+ </informalexample>
+ </para>
+ <para>
+ Egy ijesztõ példa, hogyan lehet az adatbázis gazdagépén operációs
+ rendszerszintû parancsokat futtatni.
+ <example>
+ <title>Az adatbázis-gazdagép operációs rendszere elleni támadás (MSSQL Server)</title>
+ <programlisting role="php">
<![CDATA[
<?php
@@ -311,91 +313,91 @@
?>
]]>
- </programlisting>
- </example>
- Ha a támadó az <literal>a%' exec master..xp_cmdshell 'net user test testpass /ADD' --</literal>
- értéket küldi el a <varname>$prod</varname> változónak, akkor a
- <varname>$query</varname> a következõképp alakul:
- <informalexample>
- <programlisting role="php">
+ </programlisting>
+ </example>
+ Ha a támadó az <literal>a%' exec master..xp_cmdshell 'net user test testpass /ADD' --</literal>
+ értéket küldi el a <varname>$prod</varname> változónak, akkor a
+ <varname>$query</varname> a következõképp alakul:
+ <informalexample>
+ <programlisting role="php">
<![CDATA[
$query = "SELECT * FROM products
WHERE id LIKE '%a%'
exec master..xp_cmdshell 'net user test testpass /ADD'--%'";
$result = mssql_query($query);
]]>
- </programlisting>
- </informalexample>
- MSSQL Server futtatja a kötegbe fogott SQL utasításokat, köztük azt
- is, amelyik új felhasználót vesz fel az adatbázis kiszolgálógépen. Ha
- az alkalmazás <literal>sa</literal> jogosultsággal fut és az MSSQLSERVER
- service megfelelõ jogokkal fut, akkor a támadónak most már hozzáférése van
- ehhez a géphez.
- </para>
- <note>
- <para>
- A példák némelyike bizonyos adatbáziskezelõhöz kötõdik. Ez nem azt jelenti,
- hogy hasonló támadás elképzelhetetlen más termékek ellen. Az általad
- használt adatbázis-kezelõ ugyanilyen sérülékeny lehet, akár más módon.
- </para>
- </note>
+ </programlisting>
+ </informalexample>
+ MSSQL Server futtatja a kötegbe fogott SQL utasításokat, köztük azt
+ is, amelyik új felhasználót vesz fel az adatbázis kiszolgálógépen. Ha
+ az alkalmazás <literal>sa</literal> jogosultsággal fut és az MSSQLSERVER
+ service megfelelõ jogokkal fut, akkor a támadónak most már hozzáférése van
+ ehhez a géphez.
+ </para>
+ <note>
+ <para>
+ A példák némelyike bizonyos adatbáziskezelõhöz kötõdik. Ez nem azt jelenti,
+ hogy hasonló támadás elképzelhetetlen más termékek ellen. Az általad
+ használt adatbázis-kezelõ ugyanilyen sérülékeny lehet, akár más módon.
+ </para>
+ </note>
- <sect2 id="security.database.avoiding">
- <title>Elhárítási módszerek</title>
+ <sect2 id="security.database.avoiding">
+ <title>Elhárítási módszerek</title>
+ <simpara>
+ Ellenevetésként felmerülhet, hogy a példák többségében a támadónak
+ rendelkeznie kell valamennyi elõzetes információval az adatbázis
+ felépítésérõl. Ez igaz, de soha nem lehet tudni, hogy mikor, hol, hogyan
+ szerezhetik meg ezeket, és ha ez megtörtént, az adatbázisod védtelenné
+ válik. A behatolók könnyen hozzájuthatnank a program egy darabjához nyílt
+ forráskódú, vagy olyan nyilvánosan elérhetõ adatbázis-kezelõ programcsomag
+ használatakor, amelyik egy fórum vagy tartalomszolgáltató rendszer része.
+ Ez különösen veszélyes lehet, ha ezek kevéssé átgondoltak és gyengén
+ megtervezettek.
+ </simpara>
+ <simpara>
+ Ezek a támadások alapvetõen olyan programoknak a kijátszásán alapulnak,
+ amelyek a védelmet/biztonságot figyelmen kívül hagyva születtek. Soha nem
+ lehet megbízni semmilyen bejövõ adatban, fõleg ha az a kliens oldalról
+ érkezik, még akkor sem, ha az egy általunk megadott süti (cookie), vagy
+ rejtett mezõ (hidden input) értéke esetleg egy legördülõ lista eleme.
+ Még egy olyan ártatlan lekérdezés, mint ami az elsõ példában látható,
+ katasztrófát okozhat.
+ </simpara>
+
+ <itemizedlist>
+ <listitem>
<simpara>
- Ellenevetésként felmerülhet, hogy a példák többségében a támadónak
- rendelkeznie kell valamennyi elõzetes információval az adatbázis
- felépítésérõl. Ez igaz, de soha nem lehet tudni, hogy mikor, hol, hogyan
- szerezhetik meg ezeket, és ha ez megtörtént, az adatbázisod védtelenné
- válik. A behatolók könnyen hozzájuthatnank a program egy darabjához nyílt
- forráskódú, vagy olyan nyilvánosan elérhetõ adatbázis-kezelõ programcsomag
- használatakor, amelyik egy fórum vagy tartalomszolgáltató rendszer része.
- Ez különösen veszélyes lehet, ha ezek kevéssé átgondoltak és gyengén
- megtervezettek.
+ Soha ne csatlakozz az adatbázishoz tulajdonosaként vagy superuser-ként.
+ Mindig kevés jogosultsággal rendelkezõ, testreszabott felhasználókat
+ használj!
</simpara>
+ </listitem>
+ <listitem>
<simpara>
- Ezek a támadások alapvetõen olyan programoknak a kijátszásán alapulnak,
- amelyek a védelmet/biztonságot figyelmen kívül hagyva születtek. Soha nem
- lehet megbízni semmilyen bejövõ adatban, fõleg ha az a kliens oldalról
- érkezik, még akkor sem, ha az egy általunk megadott süti (cookie), vagy
- rejtett mezõ (hidden input) értéke esetleg egy legördülõ lista eleme.
- Még egy olyan ártatlan lekérdezés, mint ami az elsõ példában látható,
- katasztrófát okozhat.
+ Ellenõrizd a bejövõ adat típusát, hogy az a vártnak megfelelõ-e! A PHP
+ a bevitelt ellenõrzõ függvények széles körével rendelkezik kezdve
+ a legegyszerûbbektõl - pl.: <link
+ linkend="ref.var">Változókkal kapcsolatos függvények</link> közül
+ <function>is_numeric</function> vagy a <link
+ linkend="ref.ctype">Character Type Functions</link> közül a
+ <function>ctype_digit</function> - a <link
+ linkend="ref.pcre">Perl kompatibilis reguláris kifejezések</link>
+ támogatásáig.
</simpara>
-
- <itemizedlist>
- <listitem>
- <simpara>
- Soha ne csatlakozz az adatbázishoz tulajdonosaként vagy superuser-ként.
- Mindig kevés jogosultsággal rendelkezõ, testreszabott felhasználókat
- használj!
- </simpara>
- </listitem>
- <listitem>
- <simpara>
- Ellenõrizd a bejövõ adat típusát, hogy az a vártnak megfelelõ-e! A PHP
- a bevitelt ellenõrzõ függvények széles körével rendelkezik kezdve
- a legegyszerûbbektõl - pl.: <link
- linkend="ref.var">Változókkal kapcsolatos függvények</link> közül
- <function>is_numeric</function> vagy a <link
- linkend="ref.ctype">Character Type Functions</link> közül a
- <function>ctype_digit</function> - a <link
- linkend="ref.pcre">Perl kompatibilis reguláris kifejezések</link>
- támogatásáig.
- </simpara>
- </listitem>
- <listitem>
- <para>
- Ha az alkalmazás számot vár, akkor megfontolandó az
- <function>is_numeric</function> függvénnyel ellenõrizni a típusát, vagy
- csendben megváltoztatni a típusát a <function>settype</function>
- függvénnyel, vagy szám szerinti ábrázolását használni az
- <function>sprintf</function> függvénnyel.
- <example>
- <title>
- A lapozáshoz használt lekérdezés összeállításának biztonságosabb módja
- </title>
- <programlisting role="php">
+ </listitem>
+ <listitem>
+ <para>
+ Ha az alkalmazás számot vár, akkor megfontolandó az
+ <function>is_numeric</function> függvénnyel ellenõrizni a típusát, vagy
+ csendben megváltoztatni a típusát a <function>settype</function>
+ függvénnyel, vagy szám szerinti ábrázolását használni az
+ <function>sprintf</function> függvénnyel.
+ <example>
+ <title>
+ A lapozáshoz használt lekérdezés összeállításának biztonságosabb módja
+ </title>
+ <programlisting role="php">
<![CDATA[
<?php
@@ -407,55 +409,55 @@
?>
]]>
- </programlisting>
- </example>
- </para>
- </listitem>
- <listitem>
- <simpara>
- Idézõjelek közé kell tenni minden nem szám jellegû, felhasználótól
- származó adatot, erre használható az adatbázis-specifikus
- escape függvény (pl. <function>mysql_escape_string</function>,
- <function>sql_escape_string</function>, stb.).
- Ha nincs ilyen adatbázis-specifikus escape mechanizmus, akkor
- hasznosnak bizonyulhatnak az <function>addslashes</function> és a
- <function>str_replace</function> függvények (az adatbázistól függõen).
- Lásd még
- <link linkend="security.database.storage">az elsõ példát</link>!
- Ahogy a példa is mutatja, a statikus részbe beírt idézõjelek
- nem elegendõek, mivel ez a lekérdezést könnyen feltörhetõvé teszi.
- </simpara>
- </listitem>
- <listitem>
- <simpara>
- Semmilyen adatbázisra jellemzõ információt - különösen
- szerkezetit - nem szabad kiírni, ha törik, ha szakad.
- Lásd még: <link
- linkend="security.errors">Hibajelzés</link> és <link
- linkend="ref.errorfunc">Hibakezelõ és naplózó függvények</link>!
- </simpara>
- </listitem>
- <listitem>
- <simpara>
- Tárolt eljársokat és elõre definiált kurzorokat is használhatsz, hogy
- az adatbázis elérést absztraháld annak érdekében, hogy a felhasználók
- ne közvetlenül a táblákhoz vagy nézetekhez férjenek hozzá. Ennek a
- megoldás azonban egyéb hatásai vannak.
- </simpara>
- </listitem>
- </itemizedlist>
-
+ </programlisting>
+ </example>
+ </para>
+ </listitem>
+ <listitem>
+ <simpara>
+ Idézõjelek közé kell tenni minden nem szám jellegû, felhasználótól
+ származó adatot, erre használható az adatbázis-specifikus
+ escape függvény (pl. <function>mysql_escape_string</function>,
+ <function>sql_escape_string</function>, stb.).
+ Ha nincs ilyen adatbázis-specifikus escape mechanizmus, akkor
+ hasznosnak bizonyulhatnak az <function>addslashes</function> és a
+ <function>str_replace</function> függvények (az adatbázistól függõen).
+ Lásd még
+ <link linkend="security.database.storage">az elsõ példát</link>!
+ Ahogy a példa is mutatja, a statikus részbe beírt idézõjelek
+ nem elegendõek, mivel ez a lekérdezést könnyen feltörhetõvé teszi.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Semmilyen adatbázisra jellemzõ információt - különösen
+ szerkezetit - nem szabad kiírni, ha törik, ha szakad.
+ Lásd még: <link
+ linkend="security.errors">Hibajelzés</link> és <link
+ linkend="ref.errorfunc">Hibakezelõ és naplózó függvények</link>!
+ </simpara>
+ </listitem>
+ <listitem>
<simpara>
- Ezeken kívül, hasznot hajthat a lekérdezések naplózása akár a szkripteken
- belül, akár ha az adatbázis kezelõ maga teszi ezt. Nyilvánvalóan ez nem
- tud megakadályozni egyetlen ártalmas próbálkozást sem, de segítséget
- nyújthat annak felderítésében, hogy melyik alkalmazás lett kijátszva. A
- naplózás önmagában nem, csak a benne megjelenõ információkon keresztül
- válik hasznossá: általában a több részlet, hasznosabb.
+ Tárolt eljársokat és elõre definiált kurzorokat is használhatsz, hogy
+ az adatbázis elérést absztraháld annak érdekében, hogy a felhasználók
+ ne közvetlenül a táblákhoz vagy nézetekhez férjenek hozzá. Ennek a
+ megoldás azonban egyéb hatásai vannak.
</simpara>
- </sect2>
- </sect1>
- </chapter>
+ </listitem>
+ </itemizedlist>
+
+ <simpara>
+ Ezeken kívül, hasznot hajthat a lekérdezések naplózása akár a szkripteken
+ belül, akár ha az adatbázis kezelõ maga teszi ezt. Nyilvánvalóan ez nem
+ tud megakadályozni egyetlen ártalmas próbálkozást sem, de segítséget
+ nyújthat annak felderítésében, hogy melyik alkalmazás lett kijátszva. A
+ naplózás önmagában nem, csak a benne megjelenõ információkon keresztül
+ válik hasznossá: általában a több részlet, hasznosabb.
+ </simpara>
+ </sect2>
+ </sect1>
+</chapter>
<!-- Keep this comment at the end of the file
Local variables:
http://cvs.php.net/viewvc.cgi/phpdoc-hu/security/errors.xml?r1=1.5&r2=1.6&diff_format=u
Index: phpdoc-hu/security/errors.xml
diff -u phpdoc-hu/security/errors.xml:1.5 phpdoc-hu/security/errors.xml:1.6
--- phpdoc-hu/security/errors.xml:1.5 Fri Mar 18 01:06:27 2005
+++ phpdoc-hu/security/errors.xml Sun Mar 18 14:58:56 2007
@@ -1,54 +1,56 @@
<?xml version="1.0" encoding="iso-8859-2"?>
-<!-- EN-Revision: 1.7 Maintainer: bagilevi Status: ready -->
+<!-- EN-Revision: 1.8 Maintainer: bagilevi Status: ready -->
+<!-- CREDITS: chappy -->
+<!-- Reviewed: no -->
<!-- HU: Last EN-Revision before HU-split: 1.48 -->
<!-- EN: Last Revision before split: 1.66 -->
<!-- EN: splitted from ./index.xml, last change in rev 1.66 -->
- <chapter id="security.errors">
- <title>Hibakezelés</title>
- <para>
- A PHP biztonsági kérdések felõl a hibajelzéseknek két oldaluk van.
- Az egyiket nézve hasznos a védelem növelése szempontjából, a másik
- szemszögbõl viszont káros.
- </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. Ha például a támadó összeszedegetett
- 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">
+<chapter id="security.errors">
+ <title>Hibakezelés</title>
+ <para>
+ A PHP biztonsági kérdések felõl a hibajelzéseknek két oldaluk van.
+ Az egyiket nézve hasznos a védelem növelése szempontjából, a másik
+ szemszögbõl viszont káros.
+ </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. Ha például a támadó összeszedegetett
+ 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.
- 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. Kifejezetten veszélyes
- beépített hibakezelõvel rendelkezõ ismert forrású kódok használata.
- Ha a támadó ráismer valamilyen általános programozási technikára, 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">
+ </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.
+ 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. Kifejezetten veszélyes
+ beépített hibakezelõvel rendelkezõ ismert forrású kódok használata.
+ Ha a támadó ráismer valamilyen általános programozási technikára, 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">
@@ -56,65 +58,65 @@
<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.
- </para>
- <para>
- 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õ.
- </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
- ad lehetõséget nyitott adatbázisportok irányában, vagy
- 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 a gyenge pontok is könnyen
- megtalálhatóak egy szkriptben.
- </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, egykori
- 'rejtett' információk könnyû kiderítését téve lehetõvé.
- </para>
- <para>
- Három megoldási lehetõség adódik erre a problémára. Az elsõ, megvizsgálni
- alaposan a függvényeket, és megpróbálni elkerülni a hibákat. A második a
- a hibajelzés kikapcsolása a teljes kódon belül. A harmadik a PHP
- testreszabható hibajelentési funkcióinak használata, hogy saját hibakezelõket
- definiálj. A már megtett biztonsági intézkedésektõl függõen esetleg
- mindhárom fenti módszert választható.
- </para>
- <para>
- Megelõzendõ a bajt hasznot hajthat a PHP beépített
- <function>error_reporting</function> függvénye, amely segít
- biztonságosabbá tenni a programokat é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ók könnyen és/vagy rosszindulatúan módosíthatók. Ha
- a program már kész bevezetésére, teljesen kikapcsolhatod a
- hibajelentést az <function>error_reporting</function> 0-ra állításával,
- vagy kikakpcsolod a hibák megmutatását a &php.ini;
- <literal>display_errors</literal> opciójával, ezzel
- teljesen leszigetelve a kódot a további vizslatásoktól.
- Ha az utóbbit választod, meg kell adnod a naplófájl útvonalát az
- <literal>error_log</literal> ini direktívával, majd a
- <literal>log_errors</literal> direktívát on-ra kell állítanod.
- <example>
- <title>Veszélyes változók felderítése az E_ALL segítségével</title>
- <programlisting role="php">
+ </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.
+ </para>
+ <para>
+ 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õ.
+ </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
+ ad lehetõséget nyitott adatbázisportok irányában, vagy
+ 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 a gyenge pontok is könnyen
+ megtalálhatóak egy szkriptben.
+ </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, egykori
+ 'rejtett' információk könnyû kiderítését téve lehetõvé.
+ </para>
+ <para>
+ Három megoldási lehetõség adódik erre a problémára. Az elsõ, megvizsgálni
+ alaposan a függvényeket, és megpróbálni elkerülni a hibákat. A második a
+ a hibajelzés kikapcsolása a teljes kódon belül. A harmadik a PHP
+ testreszabható hibajelentési funkcióinak használata, hogy saját hibakezelõket
+ definiálj. A már megtett biztonsági intézkedésektõl függõen esetleg
+ mindhárom fenti módszert választható.
+ </para>
+ <para>
+ Megelõzendõ a bajt hasznot hajthat a PHP beépített
+ <function>error_reporting</function> függvénye, amely segít
+ biztonságosabbá tenni a programokat é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ók könnyen és/vagy rosszindulatúan módosíthatók. Ha
+ a program már kész bevezetésére, teljesen kikapcsolhatod a
+ hibajelentést az <function>error_reporting</function> 0-ra állításával,
+ vagy kikakpcsolod a hibák megmutatását a &php.ini;
+ <literal>display_errors</literal> opciójával, ezzel
+ teljesen leszigetelve a kódot a további vizslatásoktól.
+ Ha az utóbbit választod, meg kell adnod a naplófájl útvonalát az
+ <literal>error_log</literal> ini direktívával, majd a
+ <literal>log_errors</literal> direktívát on-ra kell állítanod.
+ <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
@@ -125,10 +127,10 @@
}
?>
]]>
- </programlisting>
- </example>
- </para>
- </chapter>
+ </programlisting>
+ </example>
+ </para>
+</chapter>
<!-- Keep this comment at the end of the file
Local variables:
http://cvs.php.net/viewvc.cgi/phpdoc-hu/security/globals.xml?r1=1.7&r2=1.8&diff_format=u
Index: phpdoc-hu/security/globals.xml
diff -u phpdoc-hu/security/globals.xml:1.7 phpdoc-hu/security/globals.xml:1.8
--- phpdoc-hu/security/globals.xml:1.7 Mon Apr 11 19:35:16 2005
+++ phpdoc-hu/security/globals.xml Sun Mar 18 14:58:56 2007
@@ -1,38 +1,40 @@
<?xml version="1.0" encoding="iso-8859-2"?>
-<!-- EN-Revision: 1.5 Maintainer: bagilevi Status: ready -->
+<!-- EN-Revision: 1.6 Maintainer: bagilevi Status: ready -->
+<!-- CREDITS: chappy -->
+<!-- Reviewed: no -->
<!-- HU: Last EN-Revision before HU-split: 1.48 -->
<!-- EN: Last Revision before split: 1.66 -->
<!-- EN: splitted from ./index.xml, last change in rev 1.66 -->
- <chapter id="security.globals">
- <title>Globálisan is elérhetõ változók (Register Globals) használata</title>
- <para>
- A legvitatottabb változtatás a PHP-ben talán az, amikor
- <link linkend="ini.register-globals">register_globals</link>
- direktíva alapértelmezett értéke ON-ról OFF-ra változott a
- PHP <ulink url="&url.php.release4.2.0;">4.2.0</ulink>-ban.
- Erre a direktívára való támaszkodás meglehetõsen népszerû volt, sokan még
- azt sem tudták, hogy létezik és azt feltételezték, hogy ez csupán a PHP
- mûködésének tudható be.
- Ez az oldal azt taglalja, hogyan lehet nem biztonságos kódot írni ezzel a
- direktívával, de tartsd észben azt is, hogy maga a direktíva nem veszélyes,
- annál inkább az a helytelen használata.
- </para>
- <para>
- Amikor a register_globals be van állítva, megmérgezi a szkriptjeidet
- mindenféle változóval, mint például a HTML formokból származókkal. Ehhez
- hozzájön az, hogy a PHP nem követeli meg a változók inicializálását, így
- sokkal könnyeb veszélyes kódot írni. Nehéz döntés volt, de a PHP közösség
- úgy döntött, hogy ez a direktíva alap állapotban ki kell legyen kapcsolva.
- Amikor bekapcsolt állapotban van, úgy használják a változókat, hogy
- valójában nem is tudják honnan származik, csak feltételezik. A szkriptben
- definiált változók összekeverednek a felhasználótól érkezõkkel, de a
- register_globals kikapcsolása ezt megváltoztatja. Itt egy példa, amely a
- register_globals helytelen használatát szemlélteti:
- </para>
- <para>
- <example>
- <title>Helytelen használat register_globals = on esetben</title>
- <programlisting role="php">
+<chapter id="security.globals">
+ <title>Globálisan is elérhetõ változók (Register Globals) használata</title>
+ <para>
+ A legvitatottabb változtatás a PHP-ben talán az, amikor
+ <link linkend="ini.register-globals">register_globals</link>
+ direktíva alapértelmezett értéke ON-ról OFF-ra változott a
+ PHP <ulink url="&url.php.release4.2.0;">4.2.0</ulink>-ban.
+ Erre a direktívára való támaszkodás meglehetõsen népszerû volt, sokan még
+ azt sem tudták, hogy létezik és azt feltételezték, hogy ez csupán a PHP
+ mûködésének tudható be.
+ Ez az oldal azt taglalja, hogyan lehet nem biztonságos kódot írni ezzel a
+ direktívával, de tartsd észben azt is, hogy maga a direktíva nem veszélyes,
+ annál inkább az a helytelen használata.
+ </para>
+ <para>
+ Amikor a register_globals be van állítva, megmérgezi a szkriptjeidet
+ mindenféle változóval, mint például a HTML formokból származókkal. Ehhez
+ hozzájön az, hogy a PHP nem követeli meg a változók inicializálását, így
+ sokkal könnyeb veszélyes kódot írni. Nehéz döntés volt, de a PHP közösség
+ úgy döntött, hogy ez a direktíva alap állapotban ki kell legyen kapcsolva.
+ Amikor bekapcsolt állapotban van, úgy használják a változókat, hogy
+ valójában nem is tudják honnan származik, csak feltételezik. A szkriptben
+ definiált változók összekeverednek a felhasználótól érkezõkkel, de a
+ register_globals kikapcsolása ezt megváltoztatja. Itt egy példa, amely a
+ register_globals helytelen használatát szemlélteti:
+ </para>
+ <para>
+ <example>
+ <title>Helytelen használat register_globals = on esetben</title>
+ <programlisting role="php">
<![CDATA[
<?php
// $jogosult = true csak akkor ha a felhasználó sikeresen azonosítva van
@@ -49,32 +51,32 @@
}
?>
]]>
- </programlisting>
- </example>
- </para>
- <para>
- Amikor register_globals = on, a fenti logikánkon kicsit javítani kell.
- Amikor off, a <varname>$jogosult</varname> változó nem állítható be a
- felhasználótól érkezõ adatokból, tehát minden rendben, bár valójában a
- változók inicializálása rendszerint jó programozási gyakorlat. Például a
- fenti kódrészletben elõbb egy <literal>$jogosult = false</literal>
- értékadást kellett volna írnunk. Ha így teszünk, a kódunk mûködik a
- register_globals on és off értékével egyaránt, azaz a felhasználók alapból
- jogosulatlanok lesznek.
- </para>
- <para>
- Egy másik példa a <link linkend="ref.session">munkamenetkezelés</link>hez
- kötõdik.
- Amikor register_globals = on, az alábbi példában használhatnánk egy
- <varname>$usernev</varname> változót, de gondolj bele, hogy a
- <varname>$usernev</varname> máshonnan is származhat, mint például GET
- paraméterbõl (URL-en keresztül).
- </para>
- <para>
- <example>
- <title>Példa munkamenetek használatára, register_globals on vagy
- off</title>
- <programlisting role="php">
+ </programlisting>
+ </example>
+ </para>
+ <para>
+ Amikor register_globals = on, a fenti logikánkon kicsit javítani kell.
+ Amikor off, a <varname>$jogosult</varname> változó nem állítható be a
+ felhasználótól érkezõ adatokból, tehát minden rendben, bár valójában a
+ változók inicializálása rendszerint jó programozási gyakorlat. Például a
+ fenti kódrészletben elõbb egy <literal>$jogosult = false</literal>
+ értékadást kellett volna írnunk. Ha így teszünk, a kódunk mûködik a
+ register_globals on és off értékével egyaránt, azaz a felhasználók alapból
+ jogosulatlanok lesznek.
+ </para>
+ <para>
+ Egy másik példa a <link linkend="ref.session">munkamenetkezelés</link>hez
+ kötõdik.
+ Amikor register_globals = on, az alábbi példában használhatnánk egy
+ <varname>$usernev</varname> változót, de gondolj bele, hogy a
+ <varname>$usernev</varname> máshonnan is származhat, mint például GET
+ paraméterbõl (URL-en keresztül).
+ </para>
+ <para>
+ <example>
+ <title>Példa munkamenetek használatára, register_globals on vagy
+ off</title>
+ <programlisting role="php">
<![CDATA[
<?php
// Nem tudhatjuk, hogy a $usernev honnan származik, de azt igen, hogy
@@ -91,33 +93,33 @@
}
?>
]]>
- </programlisting>
- </example>
- </para>
- <para>
- Okosan használva, még azt képes lehet jelezni, ha hamisítást
- kíséreltek meg. Ha elõre tudható, hogy mely változóknak honnan
- kell érkezniük, akkor azt is megvizsgálhatod, hogy vajon más módon nem
- próbálták-e 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.
-
- Az is lehetséges, hogy megelõzõ intézkedéseket tegyünk, hogy figyelmeztetést
- kapjunk, amikor hamisítást kíséreltek meg. Ha elõre tudható, hogy mely
- változóknak pontosan honnan kell érkezniük, akkor azt is megvizsgálhatod,
- hogy vajon más módon nem próbálták-e 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.
- Ha nem számít, hogy a beküldött adat honnan jön,
- használhatod a <varname>$_REQUEST</varname>-et, mivel ez tartalmazza a GET,
- POST és COOKIE adatok keverékét. Lásd még a kézikönyv <link
- linkend="language.variables.external">PHP-n kívüli változók</link>
- használatáról szóló részt.
- </para>
- <para>
- <example>
- <title>Egyszerû "változómérgezés" feltárása</title>
- <programlisting role="php">
+ </programlisting>
+ </example>
+ </para>
+ <para>
+ Okosan használva, még azt képes lehet jelezni, ha hamisítást
+ kíséreltek meg. Ha elõre tudható, hogy mely változóknak honnan
+ kell érkezniük, akkor azt is megvizsgálhatod, hogy vajon más módon nem
+ próbálták-e 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.
+
+ Az is lehetséges, hogy megelõzõ intézkedéseket tegyünk, hogy figyelmeztetést
+ kapjunk, amikor hamisítást kíséreltek meg. Ha elõre tudható, hogy mely
+ változóknak pontosan honnan kell érkezniük, akkor azt is megvizsgálhatod,
+ hogy vajon más módon nem próbálták-e 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.
+ Ha nem számít, hogy a beküldött adat honnan jön,
+ használhatod a <varname>$_REQUEST</varname>-et, mivel ez tartalmazza a GET,
+ POST és COOKIE adatok keverékét. Lásd még a kézikönyv <link
+ linkend="language.variables.external">PHP-n kívüli változók</link>
+ használatáról szóló részt.
+ </para>
+ <para>
+ <example>
+ <title>Egyszerû "változómérgezés" feltárása</title>
+ <programlisting role="php">
<![CDATA[
<?php
if (isset($_COOKIE['MAGIC_COOKIE'])) {
@@ -139,25 +141,25 @@
}
?>
]]>
- </programlisting>
- </example>
- </para>
- <para>
- A register_globals kikapcsolása természetesen nem jelenti azt, hogy a kódod
- biztonságos. Minden beérkezõ adatot valamilyen egyéb módon is ellenõrizni
- kell. Mindig ellenõrizd a felhasználótól érkezõ adatokat és inicializáld a
- változóidat! Az inicializálatlan változók felfedezéséhez bekapcsolhatod az
- <function>error_reporting</function>-ot hogy kiírja az
- <constant>E_NOTICE</constant> szintû hibákat.
- </para>
- <para>
- A <link linkend="faq.misc.registerglobals">FAQ</link>-ban olvashatsz arról,
- hogyan lehet emulálni a register_globals On vagy Off értékét.
- </para>
+ </programlisting>
+ </example>
+ </para>
+ <para>
+ A register_globals kikapcsolása természetesen nem jelenti azt, hogy a kódod
+ biztonságos. Minden beérkezõ adatot valamilyen egyéb módon is ellenõrizni
+ kell. Mindig ellenõrizd a felhasználótól érkezõ adatokat és inicializáld a
+ változóidat! Az inicializálatlan változók felfedezéséhez bekapcsolhatod az
+ <function>error_reporting</function>-ot hogy kiírja az
+ <constant>E_NOTICE</constant> szintû hibákat.
+ </para>
+ <para>
+ A <link linkend="faq.misc.registerglobals">FAQ</link>-ban olvashatsz arról,
+ hogyan lehet emulálni a register_globals On vagy Off értékét.
+ </para>
- ¬e.superglobals;
+ ¬e.superglobals;
- </chapter>
+</chapter>
http://cvs.php.net/viewvc.cgi/phpdoc-hu/security/variables.xml?r1=1.3&r2=1.4&diff_format=u
Index: phpdoc-hu/security/variables.xml
diff -u phpdoc-hu/security/variables.xml:1.3 phpdoc-hu/security/variables.xml:1.4
--- phpdoc-hu/security/variables.xml:1.3 Sun Aug 15 17:55:01 2004
+++ phpdoc-hu/security/variables.xml Sun Mar 18 14:58:56 2007
@@ -1,19 +1,21 @@
<?xml version="1.0" encoding="iso-8859-2"?>
-<!-- EN-Revision: 1.3 Maintainer: bagilevi Status: ready -->
+<!-- EN-Revision: 1.4 Maintainer: bagilevi Status: ready -->
+<!-- CREDITS: chappy -->
+<!-- Reviewed: no -->
<!-- HU: Last EN-Revision before HU-split: 1.48 -->
<!-- EN: Last Revision before split: 1.66 -->
<!-- EN: splitted from ./index.xml, last change in rev 1.66 -->
- <chapter id="security.variables">
- <title>Felhasználótól érkezõ adatok</title>
- <para>
- A legtöbb probléma sok PHP programban nem a nyelvben rejlik, hanem
- abból fakad, hogy a kód nem a biztonságosságot szem elõtt tartva
- készült. Emiatt mindig kellõ idõt kell szánni annak ellenõrzésére,
- hogy egy adott kódrészletre milyen hatással lehet egy váratlan hibás
- adat.
- <example>
- <title>Veszélyes változóhasználat</title>
- <programlisting role="php">
+<chapter id="security.variables">
+ <title>Felhasználótól érkezõ adatok</title>
+ <para>
+ A legtöbb probléma sok PHP programban nem a nyelvben rejlik, hanem
+ abból fakad, hogy a kód nem a biztonságosságot szem elõtt tartva
+ készült. Emiatt mindig kellõ idõt kell szánni annak ellenõrzésére,
+ hogy egy adott kódrészletre milyen hatással lehet egy váratlan hibás
+ adat.
+ <example>
+ <title>Veszélyes változóhasználat</title>
+ <programlisting role="php">
<![CDATA[
<?php
// egy fájl törlése a user könyvtárából... vagy
@@ -28,56 +30,60 @@
exec ($ordogi_valtozo);
?>
]]>
- </programlisting>
- </example>
- Mindig alaposan meg kell vizsgálni a felhasználók által beadott adatokat,
- feltéve a következõ kérdéseket:
- <itemizedlist>
- <listitem>
- <simpara>
- Biztos, hogy ez a szkript csak a kívánt fájlokat fogja módosítani?
- </simpara>
- </listitem>
- <listitem>
- <simpara>
- Elõfordulhat egy ponton, hogy szokatlan vagy nem kívánatos
- adat jelenjen meg?
- </simpara>
- </listitem>
- <listitem>
- <simpara>
- Használható-e az adott szkript nem kívánatos formában?
- </simpara>
- </listitem>
- <listitem>
- <simpara>
- Felhasználható-e más szkriptekkel együtt egy negatív
- hatás elérésére?
- </simpara>
- </listitem>
- <listitem>
- <simpara>
- Megfelelõen naplózásra kerülnek-e a tranzakciók
- (elérések, változtatások)?
- </simpara>
- </listitem>
- </itemizedlist>
- Kellõképpen átgondolva a fenti kérdéseket a szkript írásakor, megkímélhet
- attól, hogy késõbb végiggondolva a problémákat szerencsétlen módon újra
- kelljen írni a teljes kódot a védelem növelése érdekében. Ezzel sem lehet
- garantálni a rendszer biztonságát, de segíthet annak növelésében/
- fenntartásában.
- </para>
- <para>
- Számításba lehet venni a register_globals, magic_quotes és más kényelmi
- szolgáltatások kikapcsolásának a gondolatát is, mivel ezek megfosztanak az
- adatok forrásának, helyességének, tartalmának ismeretétõl. A PHP*t
- maximális hibajelentési szinten használva - az error_reporting E_ALL
- beállításával - figyelmeztetést ad elõzetes érték nélküli, definiálatlan
- változókról, ezzel védve attól, hogy véletlenül hibás adatokkal dolgozzon
- a program.
- </para>
- </chapter>
+ </programlisting>
+ </example>
+ </para>
+ <para>
+ Mindig alaposan meg kell vizsgálni a felhasználók által beadott adatokat,
+ feltéve a következõ kérdéseket:
+ <itemizedlist>
+ <listitem>
+ <simpara>
+ Biztos, hogy ez a szkript csak a kívánt fájlokat fogja módosítani?
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Elõfordulhat egy ponton, hogy szokatlan vagy nem kívánatos
+ adat jelenjen meg?
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Használható-e az adott szkript nem kívánatos formában?
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Felhasználható-e más szkriptekkel együtt egy negatív
+ hatás elérésére?
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Megfelelõen naplózásra kerülnek-e a tranzakciók
+ (elérések, változtatások)?
+ </simpara>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ Kellõképpen átgondolva a fenti kérdéseket a szkript írásakor, megkímélhet
+ attól, hogy késõbb végiggondolva a problémákat szerencsétlen módon újra
+ kelljen írni a teljes kódot a védelem növelése érdekében. Ezzel sem lehet
+ garantálni a rendszer biztonságát, de segíthet annak növelésében/
+ fenntartásában.
+ </para>
+ <para>
+ Számításba lehet venni a register_globals, magic_quotes és más kényelmi
+ szolgáltatások kikapcsolásának a gondolatát is, mivel ezek megfosztanak az
+ adatok forrásának, helyességének, tartalmának ismeretétõl. A PHP*t
+ maximális hibajelentési szinten használva - az error_reporting E_ALL
+ beállításával - figyelmeztetést ad elõzetes érték nélküli, definiálatlan
+ változókról, ezzel védve attól, hogy véletlenül hibás adatokkal dolgozzon
+ a program.
+ </para>
+</chapter>
<!-- Keep this comment at the end of the file
Local variables: