cvs: phpdoc-cs / language-defs.ent /security index.xml

http://cvs.php.net/diff.php/phpdoc-cs/language-defs.ent?r1=1.10&r2=1.11&ty=u
Index: phpdoc-cs/language-defs.ent
diff -u phpdoc-cs/language-defs.ent:1.10 phpdoc-cs/language-defs.ent:1.11
--- phpdoc-cs/language-defs.ent:1.10	Thu Jan 22 17:10:49 2004
+++ phpdoc-cs/language-defs.ent	Mon Mar 15 13:37:13 2004
@@ -1,21 +1,21 @@
-<?xml encoding="iso-8859-2"?>
-<!-- EN-Revision: 1.15 Maintainer: luk Status: ready -->
-
-<!ENTITY PHPManual		"Manuál PHP">
-<!ENTITY Date			"Datum:">
-<!ENTITY GettingStarted		"Zaèínáme">
-<!ENTITY Installation           "Instalace">
-<!ENTITY LanguageReference	"Reference jazyka">
-<!ENTITY Features		"Vlastnosti">
-<!ENTITY Security		"Bezpeènost">
-<!ENTITY FunctionReference	"Reference funkcí">
-<!ENTITY Appendixes		"Dodatky">
-<!ENTITY PEAR                   "PEAR: Repozitáø roz¹íøení a aplikací PHP">
-<!ENTITY FAQ                    "FAQ: Èasto zodpovídané otázky">
-<!ENTITY FAQabbrev              "FAQ">
-<!ENTITY api			"PHP API: Rozhraní pro autory roz¹íøení PHP">
-<!ENTITY apiabbrev		"PHP API">
-<!ENTITY FunctionIndex          "Rejstøík funkcí">
-<!ENTITY CHMEdition             "Vydání HTML Help">
-<!ENTITY ReservedConstants      "Pøeddefinované konstanty">
-<!ENTITY MissingStuff           "Co zde chybí">
+<?xml encoding="iso-8859-2"?>
+<!-- EN-Revision: 1.15 Maintainer: luk Status: ready -->
+
+<!ENTITY PHPManual              "Manuál PHP">
+<!ENTITY Date                   "Datum:">
+<!ENTITY GettingStarted         "Zaèínáme">
+<!ENTITY Installation           "Instalace">
+<!ENTITY LanguageReference      "Reference jazyka">
+<!ENTITY Features               "Vlastnosti">
+<!ENTITY Security               "Bezpeènost">
+<!ENTITY FunctionReference      "Reference funkcí">
+<!ENTITY Appendixes             "Dodatky">
+<!ENTITY PEAR                   "PEAR: Repozitáø roz¹íøení a aplikací PHP">
+<!ENTITY FAQ                    "FAQ: Èasto kladené otázky">
+<!ENTITY FAQabbrev              "FAQ">
+<!ENTITY api                    "PHP API: Rozhraní pro autory roz¹íøení PHP">
+<!ENTITY apiabbrev              "PHP API">
+<!ENTITY FunctionIndex          "Rejstøík funkcí">
+<!ENTITY CHMEdition             "Vydání HTML Help">
+<!ENTITY ReservedConstants      "Pøeddefinované konstanty">
+<!ENTITY MissingStuff           "Co zde chybí">
http://cvs.php.net/diff.php/phpdoc-cs/security/index.xml?r1=1.1&r2=1.2&ty=u
Index: phpdoc-cs/security/index.xml
diff -u phpdoc-cs/security/index.xml:1.1 phpdoc-cs/security/index.xml:1.2
--- phpdoc-cs/security/index.xml:1.1	Sat Mar  6 11:11:35 2004
+++ phpdoc-cs/security/index.xml	Mon Mar 15 13:37:14 2004
@@ -55,8 +55,6 @@
     slo¾itostí.
     Vìru, nìkteré bezpeènostní útoky jsou pouze prolomení tohoto druhu
     pøehnanì stavìné bezpeènosti, která bìhem èasu povoluje.
-    Indeed, some security attacks are merely exploits of
-    this kind of overly built security, which tends to erode over time.
    </simpara>
    <simpara>
     Fráze hodná zapamatování: Systém je jen tak dobrý, jako jeho
@@ -225,60 +223,55 @@
      nikdy zobrazovány.
     </simpara>
     <simpara>
-     Also if the method for making sure the requests are not
-     redirected, as described in the previous section, is not
-     available, it is necessary to set up a script doc_root that is
-     different from web document root.
+     Také není-li k dispozici metoda k zaji¹tìní, ¾e budou po¾adavky
+     pøesmìrovávány, jak je popsáno v pøedchozí sekci, je tøeba nastavit
+     skriptový doc_root na jinou hodnotu (umístìní) ne¾ na koøenový adresáø
+     webových dokumentù.
     </simpara>
     <simpara>
-     You can set the PHP script document root by the configuration
-     directive <link linkend="ini.doc-root">doc_root</link> in the
-     <link linkend="configuration.file">configuration file</link>, or
-     you can set the environment variable
-     <envar>PHP_DOCUMENT_ROOT</envar>.  If it is set, the CGI version
-     of PHP will always construct the file name to open with this
-     <parameter>doc_root</parameter> and the path information in the
-     request, so you can be sure no script is executed outside this
-     directory (except for <parameter>user_dir</parameter>
-     below).
+     Skriptový koøenový adresáø mù¾ete nastavit konfiguraèní direktivou
+     <link linkend="ini.doc-root">doc_root</link> v
+     <link linkend="configuration.file">konfiguraèním souboru</link> nebo
+     lze také nastavit promìnnou prostøedí <envar>PHP_DOCUMENT_ROOT</envar>.
+     Je-li toto nastaveno, CGI verze PHP v¾dy zkonstruuje název souboru k otevøení
+     s tímto parametrem <parameter>doc_root</parameter> a s informací o cestì
+     v po¾adavku, tak¾e si mù¾ete být jisti, ¾e se nespustí ¾ádný skript mimo
+     tento adresáø (kromì <parameter>user_dir</parameter> - viz ní¾e).
     </simpara>
     <simpara>
-     Another option usable here is <link
-     linkend="ini.user-dir">user_dir</link>.  When user_dir is unset,
-     only thing controlling the opened file name is
-     <parameter>doc_root</parameter>.  Opening an url like <filename
-     role="url">http://my.host/~user/doc.php</filename> does not
-     result in opening a file under users home directory, but a file
-     called <filename role="uri">~user/doc.php</filename> under
-     doc_root (yes, a directory name starting with a tilde
-     [<literal>~</literal>]).
+     Jinou zde pou¾itelnou mo¾ností je parametr
+     <link linkend="ini.user-dir">user_dir</link>. Není-li nastaven, jedinou
+     vìcí, která øídí urèení názvu otevíraného souboru, je parametr
+     <parameter>doc_root</parameter>.  Otevøení URL jako <filename
+     role="url">http://my.host/~user/doc.php</filename> nezpùsobí otevøení
+     souboru pod domovským adresáøem u¾ivatele, nýbr¾ souboru nazvaného
+     <filename role="uri">~user/doc.php</filename> pod doc_root (ano, adresáøe
+     s názvem zaèínajícím vlnovkou [<literal>~</literal>]).
     </simpara>
     <simpara>
-     If user_dir is set to for example <filename
-     role="dir">public_php</filename>, a request like <filename
-     role="url">http://my.host/~user/doc.php</filename> will open a
-     file called <filename>doc.php</filename> under the directory
-     named <filename role="dir">public_php</filename> under the home
-     directory of the user.  If the home of the user is <filename
-     role="dir">/home/user</filename>, the file executed is
+     Je-li parametr user_dir nastaven napø. na  <filename
+     role="dir">public_php</filename>po¾adavek na <filename
+     role="url">http://my.host/~user/doc.php</filename> otevøe soubor s názvem
+     <filename>doc.php</filename> v adresáøi
+     <filename role="dir">public_php</filename> pod domovským adresáøem
+     u¾ivatele. Je-li domovským adresáøem  <filename
+     role="dir">/home/user</filename>, spu¹tìným souborem bude
      <filename>/home/user/public_php/doc.php</filename>.
     </simpara>
     <simpara>
-     <parameter>user_dir</parameter> expansion happens regardless of
-     the <parameter>doc_root</parameter> setting, so you can control
-     the document root and user directory access
-     separately.
+     Expanze <parameter>user_dir</parameter> se dìje bez ohledu na nastavení
+     parametru <parameter>doc_root</parameter>, tak¾e mù¾ete pøístup do
+     koøenového adresáøe dokumnetù a do domovských adresáøù øídit oddìlenì.
     </simpara>
    </sect2>
 
    <sect2 id="security.cgi-bin.shell">
     <title>Pøípad 4: PHP parser mimo WWW strom</title>
     <para>
-     A very secure option is to put the PHP parser binary somewhere
-     outside of the web tree of files.  In <filename
-     role="dir">/usr/local/bin</filename>, for example.  The only real
-     downside to this option is that you will now have to put a line
-     similar to:
+     Velmi bezpeènou mo¾ností je umístit soubor s PHP parserem nìkam mimo
+     webový strom. Napø. do adresáøe
+     <filename role="dir">/usr/local/bin</filename>. Jedinou skuteènou
+     nevýhodou je, ¾e budete nyní muset vlo¾it øádek podobný tomuto:
      <informalexample>
       <programlisting>
 <![CDATA[
@@ -286,19 +279,17 @@
 ]]>
       </programlisting>
      </informalexample>
-     as the first line of any file containing PHP tags.  You will also
-     need to make the file executable.  That is, treat it exactly as
-     you would treat any other CGI script written in Perl or sh or any
-     other common scripting language which uses the
-     <literal>#!</literal> shell-escape mechanism for launching
-     itself.
+     jako první øádek ka¾dého souboru obsahujícího PHP pøíkazy. Navíc budete
+     muset soubor nastavit jako spustitelný. Tj. nalo¾it s ním naprosto stejnì,
+     jako byste nalo¾ili s jakýmkoli jiným CGI skriptem napsaným v Perlu, sh
+     nebo jiném bì¾ném skriptovacím jazyce, který pou¾ívá ke svému spou¹tìní
+     tzv. shell-escape (<literal>#!</literal>) mechanismus.
     </para>
     <para>
-     To get PHP to handle <envar>PATH_INFO</envar> and
-     <envar>PATH_TRANSLATED</envar> information correctly with this
-     setup, the PHP parser should be compiled with the <link
-     linkend="install.configure.enable-discard-path">--enable-discard-path</link>
-     configure option.
+     Aby se v této konfiguraci správnì zpracovaly informace
+     <envar>PATH_INFO</envar> a <envar>PATH_TRANSLATED</envar>, PHP parser by
+     mìl být zkompilován s volbou <link
+     linkend="install.configure.enable-discard-path">--enable-discard-path</link>.
     </para>
    </sect2>
 
@@ -307,144 +298,138 @@
   <sect1 id="security.apache">
    <title>Instalace jako modulu do Apache</title>
    <simpara>
-    When PHP is used as an Apache module it inherits Apache's user
-    permissions (typically those of the "nobody" user). This has several
-    impacts on security and authorization. For example, if you are using
-    PHP to access a database, unless that database has built-in access
-    control, you will have to make the database accessible to the
-    "nobody" user. This means a malicious script could access and modify
-    the database, even without a username and password. It's entirely
-    possible that a web spider could stumble across a database
-    administrator's web page, and drop all of your databases. You can
-    protect against this with Apache authorization, or you can design
-    your own access model using LDAP, &htaccess; files, etc. and include
-    that code as part of your PHP scripts.
+    Pou¾ívá-li se PHP jako modul do Apache, dìdí pøístupová práva u¾ivatele
+    Apache (typicky u¾ivatele "nobody"). To pøiná¹í urèité problémy
+    s bezpeèností a autorizací. Pou¾íváte-li napøíklad PHP pro pøístup k
+    databázi, ani¾ by tato databáze mìla zabudované øízení pøístupu, budete
+    muset tuto databázi zpøístupnit u¾ivateli "nobody". To znamená, ¾e
+    ¹kodlivý skript mù¾e pøistupovat k databázi a mìnit ji bez u¾ivatelského
+    jména a hesla. Je vcelku mo¾né, ¾e webový pavouk projde pøes
+    administrátorskou stránku a znièí v¹echny va¹e databáze. Proti tomu se
+    mù¾ete chránit pomocí autorizace Apache nebo vytvoøit vlastní pøístupový
+    model za pomoci LDAP, souborù &htaccess;, apod., a vkládat tento kód do
+    va¹ich PHP skriptù.
    </simpara>
    <simpara>
-    Often, once security is established to the point where the PHP user
-    (in this case, the apache user) has very little risk attached to it,
-    it is discovered that PHP is now prevented from writing any files
-    to user directories. Or perhaps it has been prevented from accessing
-    or changing databases. It has equally been secured from writing
-    good and bad files, or entering good and bad database transactions.
+    Èasto, kdy¾ u¾ se bezpeènostní øe¹ení umístí do bodu, kde má PHP u¾ivatel
+    (v tomto pøípadì Apache u¾ivatel) malá rizika s tím spojená, se zjistí,
+    ¾e se PHP zamezilo zapisovat jakékoli soubory do u¾ivatelských adresáøù.
+    Nebo ¾e se zamezilo pøístupu nebo zmìnì databáze. To se rovná ochranì pøed
+    zápisem dobrých i ¹patných souborù, nebo provádìní dobrých i ¹patných
+    databázových transakcí.
    </simpara>
    <simpara>
-    A frequent security mistake made at this point is to allow apache
-    root permissions, or to escalate apache's abilitites in some other
-    way.
+    Èastou bezpeènostní chybou, která se v tomto místì dìlá, je pøidìlení
+    superu¾ivatelských (root) práv serveru Apache nebo jiné posílení jeho
+    pravomocí.
    </simpara>
    <simpara>
-    Escalating the Apache user's permissions to root is extremely
-    dangerous and may compromise the entire system, so sudo'ing,
-    chroot'ing, or otherwise running as root should not be considered by
-    those who are not security professionals.
+    Posílení práv u¾ivatele Apache na superu¾ivatele je extrémnì nebezpeèné
+    a mù¾e zkompromitovat celý systém, tak¾e kdo není bezpeènostní profesionál,
+    nemìl by zde pou¾ívat "su", "chroot" a podobnì pracující pøíkazy.
    </simpara>
    <simpara>
-    There are some simpler solutions. By using
-    <link linkend="ini.open-basedir">open_basedir</link> you can control and restrict what
-    directories are allowed to be used for PHP. You can also set up
-    apache-only areas, to restrict all web based activity to non-user,
-    or non-system, files.
+    Existují jednodu¹¹í øe¹ení. Pou¾itím
+    <link linkend="ini.open-basedir">open_basedir</link> mù¾ete øídit a
+    omezovat, které adresáøe lze v PHP pou¾ívat. Mù¾ete také nastavit oblasti
+    pouze pro Apache a omezit tak v¹echny webové aktivity na ne-u¾ivatelské
+    nebo ne-systémové soubory.
    </simpara>
   </sect1>
 
   <sect1 id="security.filesystem">
    <title>Bezpeènost souborového systému</title>
    <simpara>
-    PHP is subject to the security built into most server systems with
-    respect to permissions on a file and directory basis. This allows
-    you to control which files in the filesystem may be read. Care
-    should be taken with any files which are world readable to ensure
-    that they are safe for reading by all users who have access to that
-    filesystem.
+    PHP pracuje v rámci bezpeènostního modelu zabudovaného do vìt¹iny
+    serverových systémù, fungujících na bázi práv k souborùm a adresáøùm.
+    To umo¾òuje urèovat, které soubory z filesystému se smìjí èíst. Je tøeba
+    si dát pozor u souborù, které jsou èitelné "celému svìtu", z hlediska
+    zaji¹tìní, aby byly bezpeènì èitelné pro v¹echny u¾ivatele, kteøí mají
+    k tomuto souborovému systému pøístup.
    </simpara>
    <simpara>
-    Since PHP was designed to allow user level access to the filesystem,
-    it's entirely possible to write a PHP script that will allow you
-    to read system files such as /etc/passwd, modify your ethernet
-    connections, send massive printer jobs out, etc. This has some
-    obvious implications, in that you need to ensure that the files
-    that you read from and write to are the appropriate ones.
+    Jeliko¾ bylo PHP navr¾eno pro umo¾nìní pøístupu k filesystému na u¾ivatelské
+    úrovni, je vcelku mo¾né napsat PHP skript, který umo¾ní èíst systémové
+    soubory jako /etc/passwd, modifikovat va¹e ethernetová pøipojení, odesílat
+    masivní tiskové úlohy apod. To má jasné dùsledky, kdy musíte zajistit, ¾e
+    soubory, ze kterých se ète nebo do kterých se zapisuje, jsou ty správné.
    </simpara>
    <simpara>
-    Consider the following script, where a user indicates that they'd
-    like to delete a file in their home directory. This assumes a
-    situation where a PHP web interface is regularly used for file
-    management, so the Apache user is allowed to delete files in
-    the user home directories.
+    Uva¾me následující skript, kde u¾ivatel indikuje, ¾e by chtìl smazat
+    soubor v domovském adresáøi. To pøedpokládá situaci, kde webové rozhraní
+    PHP je normálnì pou¾ito ke správì souborù, tak¾e u¾ivatel Apache má
+    právo mazat soubory v domovských adresáøích u¾ivatelù.
    </simpara>
    <para>
     <example>
-     <title>Poor variable checking leads to....</title>
+     <title>Chabá kontrola promìnných vede k....</title>
      <programlisting role="php">
 <![CDATA[
 <?php
-// remove a file from the user's home directory
+// odstraò soubor z domovského adresáøe u¾ivatele
 $username = $_POST['user_submitted_name'];
 $homedir = "/home/$username";
 $file_to_delete = "$userfile";
 unlink ("$homedir/$userfile");
-echo "$file_to_delete has been deleted!";
+echo "$file_to_delete byl smazán!";
 ?>
 ]]>
      </programlisting>
     </example>
-   Since the username is postable from a user form, they can submit
-   a username and file belonging to someone else, and delete files.
-   In this case, you'd want to use some other form of authentication.
-   Consider what could happen if the variables submitted were
-   "../etc/" and "passwd". The code would then effectively read:
+   Jeliko¾ lze u¾ivatelské jméno poslat z formuláøe, lze poslat u¾ivatelské
+   jméno a název souboru kohokoliv jiného a mazat jeho soubory.
+   V takovém pøípadì byste mìli chtít pou¾ívat nìjakou formu ovìøení identity.
+   Uva¾te, co se mù¾e stát, kdyby odeslané promìnné byly "../etc/" a "passwd".
+   Kód by pak mohl efektivnì èíst:
     <example>
-     <title>... A filesystem attack</title>
+     <title>... Útok na filesystém</title>
      <programlisting role="php">
 <![CDATA[
 <?php
-// removes a file from anywhere on the hard drive that
-// the PHP user has access to. If PHP has root access:
+// odstraní soubor odkudkoli na disku, kam má PHP u¾ivatel pøístup.
+// Má-li PHP práva roota:
 $username = "../etc/";
 $homedir = "/home/../etc/";
 $file_to_delete = "passwd";
 unlink ("/home/../etc/passwd");
-echo "/home/../etc/passwd has been deleted!";
+echo "/home/../etc/passwd byl smazán!";
 ?>
 ]]>
      </programlisting>
     </example>
-    There are two important measures you should take to prevent these
-    issues.
+    Existují dvì dùle¾itá omezení, která by mìla podobným pøípadùm zabránit.
     <itemizedlist>
      <listitem>
       <simpara>
-       Only allow limited permissions to the PHP web user binary.
+       Povolte pouze omezená práva k PHP programu.
       </simpara>
      </listitem>
      <listitem>
       <simpara>
-       Check all variables which are submitted.
+       Ovìøujte v¹echny promìnné, které jsou odesílány na server.
       </simpara>
      </listitem>
     </itemizedlist>
-    Here is an improved script:
+    Tady je vylep¹ený skript:
     <example>
-     <title>More secure file name checking</title>
+     <title>Bezpeènìj¹í ovìøování názvu souboru</title>
      <programlisting role="php">
 <![CDATA[
 <?php
-// removes a file from the hard drive that
-// the PHP user has access to.
-$username = $_SERVER['REMOTE_USER']; // using an authentication mechanisim
+// odstraní soubor na disku, kam má PHP u¾ivatel pøístup.
+$username = $_SERVER['REMOTE_USER']; // pou¾ití autentizaèního mechanismu
 
 $homedir = "/home/$username";
 
-$file_to_delete = basename("$userfile"); // strip paths
+$file_to_delete = basename("$userfile"); // oøíznutí cesty
 unlink ($homedir/$file_to_delete);
 
-$fp = fopen("/home/logging/filedelete.log","+a"); //log the deletion
+$fp = fopen("/home/logging/filedelete.log","+a"); //záznam smazání
 $logstring = "$username $homedir $file_to_delete";
 fputs ($fp, $logstring);
 fclose($fp);
 
-echo "$file_to_delete has been deleted!";
+echo "$file_to_delete byl smazán!";
 ?>
 ]]>
      </programlisting>
@@ -1018,7 +1003,7 @@
   </sect1>
 
   <sect1 id="security.registerglobals">
-   <title>Using Register Globals</title>
+   <title>Registrace globálních promìnných (Register Globals)</title>
    <para>
     Perhaps the most controversial change in PHP is when the default value
     for the PHP directive <link linkend="ini.register-globals">
@@ -1156,7 +1141,7 @@
 
 
   <sect1 id="security.variables">
-   <title>User Submitted Data</title>
+   <title>Data posílaná u¾ivatelem</title>
    <para>
     The greatest weakness in many PHP programs is not inherent in the
     language itself, but merely an issue of code not being written with
@@ -1285,18 +1270,18 @@
   </sect1>
 
   <sect1 id="security.current">
-   <title>Keeping Current</title>
+   <title>Udr¾ování aktuálnosti</title>
    <simpara>
-    PHP, like any other large system, is under constant scrutiny and
-    improvement. Each new version will often include both major and
-    minor changes to enhance and repair security flaws, configuration
-    mishaps, and other issues that will affect the overall security
-    and stability of your system.
+    PHP, jako jakýkoli jiný velký systém, je podrobován neustálé kontrole a
+    vylep¹ování. Ka¾dá nová verze èasto zahrnuje jak velké, tak malé zmìny,
+    které jej roz¹iøují a opravují bezpeènostní chyby, konfiguraèní
+    nepøijemnosti a jiné skuteènosti, které mají vliv na celkovou bezpeènost
+    a stabilitu va¹eho systému.
    </simpara>
    <simpara>
-    Like other system-level scripting languages and programs, the best
-    approach is to update often, and maintain awareness of the latest
-    versions and their changes.
+    Jako u jiných skriptovacích jazykù a programù bì¾ících na systémové úrovni,
+    je nejlep¹í cestou èasto aktualizovat a hlídat si dostupnost nejnovìj¹ích
+    verzí a jejich zmìny.
    </simpara>
   </sect1>
  </chapter>