Translate the entire security/ section

security/apache.xml

@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- EN-Revision: ab6785b01ce1006e3a9761988575289f40c9b678 Maintainer: sobak Status: ready -->
+<!-- splitted from ./index.xml, last change in rev 1.66 -->
+  <chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">
+   <title>Zainstalowane jako moduł Apache</title>
+   <simpara>
+    Kiedy <acronym>PHP</acronym> jest używane jako moduł Apache, dziedziczy uprawnienia
+    użytkownika Apache (zazwyczaj te użytkownika "nobody"). Wpływa to na kilka
+    rzeczy w kwestii bezpieczeństwa i autoryzacji. Na przykład, jeśli używasz
+    <acronym>PHP</acronym> do dostępu do bazy danych, o ile ta baza nie ma wbudowanej kontroli
+    dostępu, będziesz musiał sprawić, aby baza danych była dostępna dla
+    użytkownika "nobody". Oznacza to, że złośliwy skrypt może uzyskać dostęp i modyfikować
+    dane w bazie, nawet bez nazwy użytkownika i hasła. Jest zupełnie
+    możliwe, żeby robot sieciowy natknął się na stronę administracyjną
+    bazy danych i skasował wszystkie twoje bazy danych. Możesz się
+    przed tym zabezpieczyć, używając autoryzacji Apache lub stworzyć
+    własny model dostępu używając LDAP, plików &htaccess; itd.
+   </simpara>
+   <simpara>
+    Często, po ustawieniu zabezpieczeń do tego stopnia, że użytkownik <acronym>PHP</acronym>
+    (w tym wypadku użytkownik Apache) nie stanowi już dużego zagrożenia,
+    odkrywa się, że <acronym>PHP</acronym> nie jest już w stanie zapisać żadnych plików
+    do katalogu użytkownika. Lub że nie może uzyskać dostępu do
+    ani modyfikować baz danych. Zabezpieczenia powstrzymują przed zapisywaniem
+    tych dobrych i tych złych plików lub wprowadzaniem dobrych i złych danych do bazy.
+   </simpara>
+   <simpara>
+    Częstą pomyłką bezpieczeństwa czynioną w tym momencie jest pozwolenie Apache
+    na działanie z uprawnieniami roota albo zwiększenie uprawnień Apache w inny
+    sposób.
+   </simpara>
+   <simpara>
+    Zwiększanie uprawnień użytkownika Apache do roota jest skrajnie
+    niebezpieczne i może narazić cały system, więc użycie sudo,
+    chroot lub uruchamianie jako root w inny sposób nie powinno być nawet rozważane,
+    o ile nie jesteś specjalistą z zakresu bezpieczeństwa.
+   </simpara>
+   <simpara>
+    Istnieją pewne prostsze sposoby. Używając
+    <link linkend="ini.open-basedir">open_basedir</link> możesz kontrolować i ograniczać
+    katalogi, które mogą być używane przez <acronym>PHP</acronym>. Możesz także ustawić
+    obszary tylko dla Apache, aby zabronić aktywności pochodzącej z sieci dla katalogów
+    innych niż danego użytkownika.
+   </simpara>
+  </chapter>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:t
+sgml-shorttag:t
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:t
+indent-tabs-mode:nil
+sgml-parent-document:nil
+sgml-default-dtd-file:"~/.phpdoc/manual.ced"
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+vim600: syn=xml fen fdm=syntax fdl=2 si
+vim: et tw=78 syn=sgml
+vi: ts=1 sw=1
+-->

security/cgi-bin.xml

@@ -0,0 +1,246 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- EN-Revision: 87d3bf2e9ea7da5abbeca3e60ea7cf7abfa6f7f3 Maintainer: sobak Status: ready -->
+<!-- splitted from ./index.xml, last change in rev 1.66 -->
+  <chapter xml:id="security.cgi-bin" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
+   <title>Zainstalowane jako program CGI</title>
+
+   <sect1 xml:id="security.cgi-bin.attacks">
+    <title>Możliwe ataki</title>
+    <simpara>
+     Użycie PHP jako program <acronym>CGI</acronym> jest opcją dla
+     osób, które z jakiegoś powodu nie chcą integrować PHP jako
+     moduł do ich serwera WWW (np. Apache), lub które będą używać PHP
+     z innymi rodzajami wrapperów <acronym>CGI</acronym> aby stworzyć bezpieczne
+     środowiska dla skryptów używając
+     <command>chroot</command> i <command>setuid</command>. Takie środowisko zazwyczaj opiera się o zainstalowanie
+     programu wykonywalnego <command>php</command> do katalogu <filename class="directory">cgi-bin</filename> serwera WWW.
+     Rekomendacja CERT <link xlink:href="&url.cert;">CA-96.11</link> zaleca
+     nie umieszczać żadnych interpreterów w <filename class="directory">cgi-bin</filename>.
+     Nawet jeśli plik binarny <command>php</command> może być użyty jako samodzielny interpreter,
+     PHP jest zaprojektowane tak, aby zapobiegać atakom, które są możliwe przy takim środowisku:
+    </simpara>
+    <itemizedlist>
+     <listitem>
+      <simpara>
+       Dostęp do plików systemowych: <filename
+       role="url">http://my.host/cgi-bin/php?/etc/passwd</filename>
+      </simpara>
+      <simpara>
+       Informacje o zapytaniu w adresie URL (tzw. query string) po znaku zapytania (<literal>?</literal>) są
+       przekazywane jako argumenty wiersza poleceń do interpretera przez interfejs
+       CGI. Zazwyczaj interpretery otwierają i wykonują plik
+       podany jako pierwszy argument w wierszu poleceń.
+      </simpara>
+      <simpara>
+       Kiedy wywoływany jest jako program CGI, <command>php</command> odmówi zinterpretowania
+       argumentów wiersza poleceń.
+      </simpara>
+     </listitem>
+     <listitem>
+      <simpara>
+       Dostęp do dowolnego dokumentu na serwerze: <filename
+       role="url">http://my.host/cgi-bin/php/secret/doc.html</filename>
+      </simpara>
+      <simpara>
+       Część adresu URL będąca ścieżką po nazwie pliku binarnego PHP,
+       <filename role="uri">/secret/doc.html</filename> jest
+       zgodnie z konwencją używana do określenia nazwy pliku do
+       otwarcia i zinterpretowania przez program <acronym>CGI</acronym>.
+       Zazwyczaj używane są pewne dyrektywy konfiguracyjne serwera WWW (Apache:
+       <literal>Action</literal>) są używane do przekierowania żądań o dokumenty jak
+       <filename
+       role="url">http://my.host/secret/script.php</filename> do
+       interpretera PHP. Przy takim ustawieniu, serwer WWW najpierw sprawdza
+       uprawnienia dostępu do katalogu <filename
+       role="uri">/secret</filename>, a potem tworzy
+       przekierowane żądanie <filename
+       role="url">http://my.host/cgi-bin/php/secret/script.php</filename>.
+       Niestety, jeśli żądanie jest od razu przekazane w tej postaci,
+       serwer nie wykonuje żadnych sprawdzeń dostępu dla pliku <filename
+       role="uri">/secret/script.php</filename>, lecz tylko dla pliku
+       <filename role="uri">/cgi-bin/php</filename>. W ten sposób
+       każdy użytkownik, który ma dostęp do <filename
+       role="uri">/cgi-bin/php</filename> jest w stanie uzyskać dostęp do dowolnego
+       chronionego dokumentu na serwerze WWW.
+      </simpara>
+      <simpara>
+       W PHP dyrektywy konfiguracyjne <link
+       linkend="ini.cgi.force-redirect">cgi.force_redirect</link>, <link
+       linkend="ini.doc-root">doc_root</link> oraz <link
+       linkend="ini.user-dir">user_dir</link> mogą zostać wykorzystane do zapobieżenia
+       temu atakowi, jeśli struktura katalogów na serwerze ma jakieś katalogi
+       z ograniczeniami dostępu. Zobacz poniżej, żeby zapoznać się z pełnym objaśnieniem
+       różnych ich kombinacji.
+      </simpara>
+     </listitem>
+    </itemizedlist>
+   </sect1>
+
+   <sect1 xml:id="security.cgi-bin.default">
+    <title>Przypadek 1: obsługiwane są tylko publiczne pliki</title>
+
+    <simpara>
+     Jeżeli Twój serwer nie ma żadnej zawartości, która nie jest zastrzeżona
+     przez kontrolę dostępu opartą o hasło lub adres IP, nie ma potrzeby użycia
+     tych opcji konfiguracyjnych. Jeśli Twój serwer nie pozwala
+     wykonywać przekierowań lub jeśli serwer nie ma sposobu, aby 
+     zakomunikować plikowi binarnemu PHP, że żądanie jest bezpiecznie
+     przekierowanym żądaniem, możesz włączyć dyrektywę INI
+     <link linkend="ini.cgi.force-redirect">cgi.force_redirect</link>.
+     Wciąż musisz się upewnić, że Twoje skrypty PHP
+     nie zależą od konkretnej metody wywoływania skryptu,
+     czy to bezpośrednio przez <filename
+     role="php">http://my.host/cgi-bin/php/dir/script.php</filename>,
+     czy przez przekierowanie: <filename
+     role="php">http://my.host/dir/script.php</filename>.
+    </simpara>
+    <simpara>
+     Przekierowanie może być ustawione w Apache używając dyrektyw <literal>AddHandler</literal> i
+     <literal>Action</literal> (patrz poniżej).
+    </simpara>
+   </sect1>
+
+   <sect1 xml:id="security.cgi-bin.force-redirect">
+    <title>Przypadek 2: użycie <literal>cgi.force_redirect</literal></title>
+    <simpara>
+     Dyrektywa konfiguracyjna <link
+     linkend="ini.cgi.force-redirect">cgi.force_redirect</link>
+     zapobiega wywołaniu <command>php</command>
+     bezpośrednio w adresie URL, np. <filename
+     role="php">http://my.host/cgi-bin/php/secretdir/script.php</filename>.
+     PHP będzie parsowało pliki w tym trybie tylko jeśli przekierowanie
+     pochodzi z reguły serwera WWW.
+    </simpara>
+    <simpara>
+     Zazwyczaj przekierowanie jest wykonywane w konfiguracji Apache w
+     następujący sposób:
+    </simpara>
+    <programlisting role="apache-conf">
+<![CDATA[
+Action php-script /cgi-bin/php
+AddHandler php-script .php
+]]>
+    </programlisting>
+    <simpara>
+     Ta opcja została przetestowana tylko z serwerem Apache i
+     opiera się o ustawienie niestandardowej zmiennej środowiskowej CGI
+     <envar>REDIRECT_STATUS</envar> przez Apache dla przekierowanych żądań. Jeśli Twój
+     serwer WWW nie wspiera żadnego sposobu zakomunikowania czy żądanie jest
+     bezpośrednie czy przekierowane, nie możesz użyć tej opcji i musisz
+     użyć jednej z innych metod uruchamiania CGI opisanych
+     w tym dokumencie.
+    </simpara>
+   </sect1>
+
+   <sect1 xml:id="security.cgi-bin.doc-root">
+    <title>Przypadek 3: ustawienie doc_root lub user_dir</title>
+    <simpara>
+     Umieszczanie aktywnej zawartości jak skrypty i pliki wykonywalne w
+     katalogu dokumentów serwera WWW jest czasem uznawane za niebezpieczną
+     praktykę. Jeśli na skutek mylnej konfiguracji skrypty
+     nie zostaną wykonane a wyświetlone jak zwykłe dokumenty HTML, to
+     skutkiem może być wyciek własności intelektualnej lub informacji
+     bezpieczeństwa, takich jak hasła. W związku z tym wielu administratorów preferuje
+     stworzenie innej struktury katalogów dla skryptów, które są
+     dostępne tylko przez PHP CGI i w związku z tym zawsze są
+     interpretowane, a nigdy nie wyświetlane bezpośrednio.
+    </simpara>
+    <simpara>
+     Ponadto, jeśli metoda upewnienia się, że żądania nie są
+     przekierowane (jak opisano w poprzedniej sekcji) nie jest
+     dostępna, konieczne jest ustawienie
+     opcji <link linkend="ini.doc-root">doc_root</link> dla skryptu,
+     której wartość będzie inna niż ścieżka katalogu dokumentów serwera WWW.
+    </simpara>
+    <simpara>
+     Katalog główny skryptów PHP można ustawić dyrektywą
+     konfiguracyjną <link linkend="ini.doc-root">doc_root</link> w
+     <link linkend="configuration.file">pliku konfiguracyjnym</link> lub
+     ustawiając zmienną środowiskową
+     <envar>PHP_DOCUMENT_ROOT</envar>. Gdy ta opcja jest ustawiona PHP w
+     wersji <acronym>CGI</acronym> zawsze skonstruuje nazwę pliku do otwarcia z
+     użyciem <parameter>doc_root</parameter> i informacji o ścieżce w
+     żądaniu. Dzięki temu możesz mieć pewność, że żaden skrypt nie zostanie
+     wykonany poza tym katalogiem (poza <parameter>user_dir</parameter>,
+     patrz niżej).
+    </simpara>
+    <simpara>
+     Inną opcją której można użyć jest <link
+     linkend="ini.user-dir">user_dir</link>.  Gdy <parameter>user_dir</parameter> nie
+     jest ustawiona, jedynym ustawieniem wpływającym na nazwę otwieranego pliku jest
+     <parameter>doc_root</parameter>. Otwarcie adresu URL jak np. <filename
+     role="url">http://my.host/~user/doc.php</filename> nie
+     skutkuje otwarciem pliku w katalogu domowym użytkownika, lecz pliku
+     nazywającego się <filename role="uri">~user/doc.php</filename> w katalogu
+     <parameter>doc_root</parameter> (tak, katalogu zaczynającego się od tyldy
+     [<literal>~</literal>]).
+    </simpara>
+    <simpara>
+     Jeśli <parameter>user_dir</parameter> jest ustawiona przykładowo na <filename
+     role="dir">public_php</filename>, żądanie takie jak <filename
+     role="url">http://my.host/~user/doc.php</filename> otworzy
+     plik <filename>doc.php</filename> w katalogu
+     nazwanym <filename role="dir">public_php</filename> w katalogu
+     domowym użytkownika. Jeśli katalog domowy użytkownika to <filename
+     role="dir">/home/user</filename>, to wykonanym plikiem będzie
+     <filename>/home/user/public_php/doc.php</filename>.
+    </simpara>
+    <simpara>
+     Opcja <parameter>user_dir</parameter> działa niezależnie od
+     ustawienia <parameter>doc_root</parameter>, tak więc możesz kontrolować
+     dostęp do katalogu głównego dokumentów i katalogu użytkownika
+     osobno.
+    </simpara>
+   </sect1>
+
+   <sect1 xml:id="security.cgi-bin.shell">
+    <title>Przypadek 4: parser PHP poza drzewem dokumentów serwera WWW</title>
+    <para>
+     Bardzo bezpiecznym rozwiązaniem jest umieszczenie parsera PHP gdzieś
+     poza drzewem dokumentów webowych. Na przykład w <filename
+     role="dir">/usr/local/bin</filename>. Jedyną faktyczną
+     wadą takiego rozwiązania jest konieczność umieszczenia linii
+     podobnej do:
+     <informalexample>
+      <programlisting>
+<![CDATA[
+#!/usr/local/bin/php
+]]>
+      </programlisting>
+     </informalexample>
+     jako pierwszej linii w dowolnym pliku zawierającym tagi PHP. Będziesz też
+     musiał uczynić plik wykonywalnym. To znaczy traktować go tak, jak
+     traktowałbyś dowolny inny skrypt CGI napisany w Perlu, sh lub dowolnym
+     innym powszechnym języku skryptowym, który używa
+     mechanizmu powłoki <literal>#!</literal> do uruchomienia samego
+     siebie.
+    </para>
+    <para>
+     Aby PHP obsługiwało poprawnie informacje <envar>PATH_INFO</envar> i
+     <envar>PATH_TRANSLATED</envar> przy tym ustawieniu, musisz włączyć
+     dyrektywę INI <link linkend="ini.cgi.discard-path">cgi.discard_path</link>.
+    </para>
+   </sect1>
+
+  </chapter>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:t
+sgml-shorttag:t
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:t
+indent-tabs-mode:nil
+sgml-parent-document:nil
+sgml-default-dtd-file:"~/.phpdoc/manual.ced"
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+vim600: syn=xml fen fdm=syntax fdl=2 si
+vim: et tw=78 syn=sgml
+vi: ts=1 sw=1
+-->

security/current.xml

@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- EN-Revision: 96c9d88bad9a7d7d44bfb7f26c226df7ee9ddf26 Maintainer: sobak Status: ready -->
+<!-- splitted from ./index.xml, last change in rev 1.66 -->
+  <chapter xml:id="security.current" xmlns="http://docbook.org/ns/docbook">
+   <title>Pozostawanie na bieżąco</title>
+   <simpara>
+    PHP, tak jak każdy inny wielki system, jest stale kontrolowany
+    i ulepszany. Nowa wersje często zawierają mniejsze i
+    większe zmiany mające na celu poprawę bezpieczeństwa i usunięcie luk, błędnej
+    konfiguracji i innych problemów, które wpływają na ogólny
+    poziom zabezpieczeń i stabilność Twojego systemu.
+   </simpara>
+   <simpara>
+    Tak jak i przy innych językach i programach skryptowych działających na poziomie systemu, najlepszym
+    sposobem jest częste pobieranie aktualizacji i pozostawanie na bieżąco z najnowszymi
+    wydaniami oraz zmianami w nich.
+   </simpara>
+  </chapter>
+
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:t
+sgml-shorttag:t
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:t
+indent-tabs-mode:nil
+sgml-parent-document:nil
+sgml-default-dtd-file:"~/.phpdoc/manual.ced"
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+vim600: syn=xml fen fdm=syntax fdl=2 si
+vim: et tw=78 syn=sgml
+vi: ts=1 sw=1
+-->