archived-doc-pl/security/cgi-bin.xml

<?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
-->