gerzson Sun Feb 10 20:22:14 2002 EDT
Modified files:
/phpdoc/hu/chapters security.xml
Log:
correct some conversation issues
Index: phpdoc/hu/chapters/security.xml
diff -u phpdoc/hu/chapters/security.xml:1.21 phpdoc/hu/chapters/security.xml:1.22
--- phpdoc/hu/chapters/security.xml:1.21 Mon Feb 4 06:52:41 2002
+++ phpdoc/hu/chapters/security.xml Sun Feb 10 20:22:14 2002
@@ -501,10 +501,10 @@
<title>Adatbázis biztonság</title>
<simpara>
- Mostanában, bármely dinamikus tartalmat szolgáltató web alapú alkalmazás
- sarokkövének számítanak az adatbázisok. Mivel nagyon kényes, titkos adatok
- tárolására szolgálnak ezek az adatbázisok, erősen megfontolandó, hogyan
- védjük meg az ezeket.
+ 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
@@ -515,7 +515,7 @@
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.
+ Mint látható, a PHP egymagában, magától nem képes megvédeni az adatbázist.
A következő bekezdések élja, hogy betekintést adjanak az alapokba, hogyan kell
adatbázisokat elérni és módosítani egy PHP programon belül.
</simpara>
@@ -531,9 +531,9 @@
<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, 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.
+ 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>
@@ -541,7 +541,7 @@
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 teljes törlésü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-
@@ -591,23 +591,22 @@
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 csillapítja ezt a veszélyt, de jelenleg
+ 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 a segítséget
+ 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. Az szkript először titkosítja a tárolni kívánt
- adatot, majd a későbbiekben visszakereséskor visszafejti azokat. Nézd
- meg a hivatkozott fejezeteket további példákért, hogyan kell a titkosítást
- végrehajtani.
+ algoritmust fednek le. A szkript először 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 teljsen rejtett adatok esetén, amelyeknek nyílt ábrázolásukra nincs
- szükség, mert nem lesznek kiíratva, a hashelést alkalmazása is
+ 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>!
@@ -641,11 +640,11 @@
<title>SQL "beoltás"</title>
<simpara>
Sok web fejlesztő nincs tudatában annak, hogy hogyan lehet megbabrálni
- az SQL utasításokat, és feltételezik, hogy az SQL uatsítás az egy megbízható
- parancs. Ez azt jelenti, hogy az SQL lekérdezésekkel ki lehet játszani a
- hozzáférés-szabályozásokat, ennélfogva a szabályos engedélyezési folyamatokat
- megkerülni, és néha az SQL lekérdezésekkel a gazdagépen operációs rendszer
- szintű hozzáférést lehet létrehozni.
+ az SQL utasításokat, és 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, a szabályos engedélyezési
+ folyamatokat megkerülni, és néha az SQL lekérdezésekkel a gazdagépen
+ operációs rendszer szintű hozzáférést lehet létrehozni.
</simpara>
<simpara>
A "közvetlen SQL utasítás befecskendezés" olyan módszer, amellyel a támadó
@@ -681,23 +680,19 @@
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 fűzi hozzá
- az URL-hez (PostgreSQL):
+ a következő utasítás <function>urlencode</function> alakját hozzáfűzni
+ az URL-hez:
<informalexample>
<programlisting>
<![CDATA[
+// PostgreSQL
0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
select 'crack', usesysid, 't','t','crack'
from pg_shadow where usename='postgres';
--
-]]>
- </programlisting>
- </informalexample>
- vagy MySQL esetén
- <informalexample>
- <programlisting>
-<![CDATA[
+
+// vagy MySQL esetén
0;
UPDATE user SET Password=PASSWORD('crack') WHERE user='root';
FLUSH PRIVILEGES;
@@ -751,19 +746,19 @@
]]>
</programlisting>
</informalexample>
- Ha ez 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.
+ 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 UPDATEs 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.
+ 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ő)
@@ -783,17 +778,17 @@
<informalexample>
<programlisting role="php">
<![CDATA[
-// $uid == ' or uid like'%admin%'; --
-$query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --";
+// $uid == "' or uid like'%admin%'; --"
+$query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --';";
// $pwd == "hehehe', admin='yes', trusted=100 "
-$query = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...;"
+$query = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ...";
]]>
</programlisting>
</informalexample>
</para>
<para>
- Egy ijesztő példa arról, hogyan lehet az adatbázis gazdagépén operációs
+ 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>
@@ -810,7 +805,7 @@
<informalexample>
<programlisting role="php">
<![CDATA[
-$query = "SELECT * FROM products WHERE id LIKE '%a%' exec master..xp_cmdshell 'net
user test testpass /ADD'--";
+$query = "SELECT * FROM products WHERE id LIKE '%a%' exec master..xp_cmdshell 'net
+user test testpass /ADD'--%'";
$result = mssql_query($query);
]]>
</programlisting>
@@ -832,7 +827,7 @@
<sect3 id="security.database.avoiding">
<title>Elhárítási módszerek</title>
<simpara>
- Ellenevetésként felmerülhet, hogy példák többségében a támadónak
+ 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é
@@ -843,9 +838,9 @@
megtervezettek.
</simpara>
<simpara>
- Ezek a támadások alapvetően azoknak a programoknak a kihasználásán alapulnak,
+ 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ő adaton, főleg ha az a kliens oldalról
+ 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ó,
@@ -919,7 +914,7 @@
<listitem>
<simpara>
Tárolt eljársokat és előre definiált kurzorokat is használhatsz, hogy
- az adatbáziselérést absztraháld annak érdekében, hogy a felhasználók
+ 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>
@@ -928,8 +923,8 @@
<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ó, hogy ez nem
- tudja megakadályozni egyetlen ártalmas próbálkozást sem, de segítséget
+ 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.
@@ -942,7 +937,8 @@
<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 káros rá.
+ 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
