cvs: phpdoc-ro /security cgi-bin.xml

zamolxe Sun Feb 29 10:32:04 2004 EDT Added files: /phpdoc-ro/security cgi-bin.xml Log: tradus si adaptat PHP ca binar CGI v.1

http://cvs.php.net/co.php/phpdoc-ro/security/cgi-bin.xml?r=1.1&p=1 Index: phpdoc-ro/security/cgi-bin.xml +++ phpdoc-ro/security/cgi-bin.xml <?xml version="1.0" encoding="iso-8859-1"?> <!-- $Revision: 1.1 $ --> <!-- splitted from ./index.xml, last change in rev 1.66 --> <sect1 id="security.cgi-bin"> <title>Instalat ca un binar CGI</title> <sect2 id="security.cgi-bin.attacks"> <title>Atacuri posibile</title> <simpara> Folosind PHP ca pe un binar <acronym>CGI</acronym> este o optiune pe care setup-urile, dintr-un anume motiv, nu doresc sa o configureze si sa o integreze in PHP ca pe un modul in serverul software (precum Apache), sau vor folosi PHP cu ajutorul diferitelor metode de CGI wrap pentru a crea medii securizate chroot si setuid pentru scripturi. Acest setup implica de obicei instalarea binarului PHP executabil in directorul cgi-bin din serverul web. Indrumarul CERT <ulink url="&url.cert;">CA-96.11</ulink> nu recomanda plasarea oricarui tip de interpretor de acest gen in directorul cgi-bin. Chiar daca binarul PHP poate fi folosit ca un interpretor de sine statator, PHP a fost conceput in asa fel incat sa anticipeze atacuri generate de un asemenea setup: </simpara> <itemizedlist> <listitem> <simpara> Accesarea fisierelor din sistem: <filename role="url">http://www.host_victima.ro/cgi-bin/php?/etc/passwd</filename> </simpara> <simpara> Informatia din URL de dupa semnul de intrebare (?) este pasata liniei de comanda ca argumente si interpretata de interfata CGI. De obicei interpretoarele deschid si executa fisierul specificat ca prim argument in linia de comanda. </simpara> <simpara> Cand este apelat ca un binar CGI, PHP refuza sa interpreteze argumentele din linia de comanda. </simpara> </listitem> <listitem> <simpara> Puteti accesa orice document de pe server: <filename role="url">http://www.host_victima.ro/cgi-bin/php/secret/doc.html</filename> </simpara> <simpara> Informatiile introduse in URL dupa numele binarului PHP, <filename role="uri">/secret/doc.html</filename> sunt de obicei utilizate pentru a specifica numele si calea catre fisierul care trebuie deschis de catre interpretorul <acronym>CGI</acronym>. De obicei directivele din configuratia unui server web (Apache: Action) sunt folosite pentru a redirecta cererile catre documente ca <filename role="url">http://www.host_victima.ro/secret/script.php</filename> catre interpretorul PHP. Cu acest setup, serverul web verifica mai intai permisiile de acces catre directorul <filename role="uri">/secret</filename>, si dupa aceea creaza cererea de redirectionare catre <filename role="url">http://www.host.ro/cgi-bin/php/secret/script.php</filename>. Din pacate, daca cererea originala se face sub aceasta forma nu sunt facute nici un fel de verificari de catre serverul web catre fisierul <filename role="uri">/secret/script.php</filename>, ci numai pentru fisierul <filename role="uri">/cgi-bin/php</filename>. In acest fel, orice utilizator care poate executa <filename role="uri">/cgi-bin/php</filename>, poate accesa automat orice director sau fisier protejat de pe server. </simpara> <simpara> In PHP, optiunea din timpul compilarii <link linkend="install.configure.enable-force-cgi-redirect">--enable-force-cgi-redirect</link> si directivele de configuratie <link linkend="ini.doc-root">doc_root</link> si <link linkend="ini.user-dir">user_dir</link> pot fi folosite pentru a preveni acest atac, daca structura documentelor de pe server contine vreun director cu acces restrictionat. Observati mai jos explicatii detaliate despre diferite combinatii. </simpara> </listitem> </itemizedlist> </sect2> <sect2 id="security.cgi-bin.default"> <title>Cazul 1: numai fisierele publice sunt servite clientului</title> <simpara> Daca serverul dumneavoastra nu are nici un fel de continut (directoare/fisiere) care este restrictionat prin parola sau pe baza de IP, atunci nu este nevoie de aceste configuratii. Daca serverul web nu da voie la redirectari, sau nu comunica cu binarul PHP pentru a-i transmite daca cererea este una sigura, puteti specifica optiunea <link linkend="install.configure.enable-force-cgi-redirect">--enable-force-cgi-redirect</link> scriptului de configurare. Totusi trebuie sa va asigurati ca scripturile dumneavoastra PHP nu depind intr-un fel sau altul de modul in care este facuta cererea - direct <filename role="php">http://my.host/cgi-bin/php/dir/script.php</filename> sau prin redirectie <filename role="php">http://my.host/dir/script.php</filename>. </simpara> <simpara> Redirectarea poate fi configurata in Apache folosind directivele AddHandler si Action (vezi mai jos). </simpara> </sect2> <sect2 id="security.cgi-bin.force-redirect"> <title>Cazul 2: utilizarea --enable-force-cgi-redirect</title> <simpara> Aceasta optiune disponibila in timpul compilarii este folosita pentru a preveni rularea unui script PHP direct printr-un URL gen <filename role="php">http://my.host/cgi-bin/php/secretdir/script.php</filename>. In schimb, PHP va actiona in acest mod numai dupa ce se va trece de regulile impuse de redirectionare din serverul web. </simpara> <simpara> De obicei redirectarea in configuratia Apache se face dupa urmatoarele directive: </simpara> <programlisting role="apache-conf"> <![CDATA[ Action php-script /cgi-bin/php AddHandler php-script .php ]]> </programlisting> <simpara> Aceasta optiune a fost testata numai cu serverul Apache, si se bazeaza pe setarea variabilei non-standard CGI <envar>REDIRECT_STATUS</envar>, pentru cererile de redirectionare. Daca serverul dumneavoastra nu suporta nici o metoda de a analiza daca o cerere este directa sau redirectata, nu puteti folosi aceasta optiune, si trebuie sa folositi alte cai descrise in subcapitolele de mai jos. </simpara> </sect2> <sect2 id="security.cgi-bin.doc-root"> <title>Cazul 3: configurarea doc_root sau user_dir</title> <simpara> Includerea de continut activ, de pilda scripturi si executabile, in directoarele serverului web este de multe ori considerata o metoda nesecurizata. Daca, din cauza unor configuratii gresite, scripturile nu sunt executate ci afisate ca documente HTML, atunci securitatea si informatii vitale cum ar fi parolele pot fi desconspirate. De aceea multi administratori de sistem configureaza un director creat special, in care ruleaza scripturi accesibile numai via PHP CGI, deci care sunt interpretate tot timpul ca atare. </simpara> <simpara> De asemenea daca metoda de transmitere a cererilor, descrisa mai sus, nu este disponibila, atunci este necesara configurarea unui director doc_root care este diferit de documentul web root. </simpara> <simpara> Puteti configura documentul radacina al scripturilor PHP prin directiva <link linkend="ini.doc-root">doc_root</link> din <link linkend="configuration.file">fisierul de configuratie</link>, sau puteti configura variabila de mediu <envar>PHP_DOCUMENT_ROOT</envar>. Daca este setata, versiunea PHP pe care o detineti va constui intotdeauna numele fisierului deschis din <parameter>doc_root</parameter> si informatiile despre cale din cerere, pentru a fi siguri ca scriptul este executat in afara acestui director (exceptie facand <parameter>user_dir</parameter> de mai jos). </simpara> <simpara> Alta optiune folosita este <link linkend="ini.user-dir">user_dir</link>. Cand user_dir nu este configurat, singurul lucru care controleaza fisierul deschis este <parameter>doc_root</parameter>. Deschiderea unui URL ca <filename role="url">http://my.host/~user/doc.php</filename> nu rezulta din accesarea unui fisier din directorul home al utilizatorilor, ci a unui fisier numit <filename role="uri">~user/doc.php</filename> din doc_root (da, un director a carui nume incepe cu tilda [<literal>~</literal>]). </simpara> <simpara> Daca user_dir este configurat spre exemplu ca <filename role="dir">public_php</filename>, o cerere in genul <filename role="url">http://my.host/~user/doc.php</filename> va deschide un fisier numit <filename>doc.php</filename> din directorul numit <filename role="dir">public_php</filename> aflat sub directorul radacina al utilizatorului user. Daca directorul radacina al utilizatorului user este <filename role="dir">/home/user</filename>, fisierul executat este <filename>/home/user/public_php/doc.php</filename>. </simpara> <simpara> Expansiunea <parameter>user_dir</parameter> se poate face fara a tine cont de paramentrul <parameter>doc_root</parameter> din setari, deci puteti controla accesul la directorul radacina si la directoarele utilizatorilor in mod separat. </simpara> </sect2> <sect2 id="security.cgi-bin.shell"> <title>Cazul 4: parserul PHP in afara directorului radacina web</title> <para> O metoda foarte sigura si eleganta este de a plasa compilatorul PHP in afara directorului radacina web. In <filename role="dir">/usr/local/bin</filename>, spre exemplu. Singura dezamagire pe care o veti avea, este ca trebuie sa puneti urmatoarea linie: <informalexample> <programlisting> <![CDATA[ #!/usr/local/bin/php ]]> </programlisting> </informalexample> la inceputul fiecarui fisier care contine taguri PHP. De asemenea va trebui sa faceti fisierul executabil. Acesta este tratat exact ca un script CGI scris in Perl sau sh sau orice alt limbaj de scripting care utilizeaza <literal>#!</literal> mecanismul shell-escape pentru a se lansa. </para> <para> Pentru ca PHP sa utilizeze informatiile <envar>PATH_INFO</envar> si <envar>PATH_TRANSLATED</envar> in mod corect, acesta trebuie compilat cu optiunea de configurare<link linkend="install.configure.enable-discard-path">--enable-discard-path</link> </para> </sect2> </sect1> <!-- 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:"../../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 -->