Skip to content

Commit 3f82489

Browse files
ManueldGManueldG
committed
git pull
1 parent 2450bc2 commit 3f82489

File tree

10 files changed

+1472
-0
lines changed

10 files changed

+1472
-0
lines changed

‎security/cgi-bin.xml‎

Lines changed: 243 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,243 @@
1+
<?xml version="1.0" encoding="utf-8"?>
2+
<!-- $Revision$ -->
3+
<!-- EN-Revision: 87d3bf2e9ea7da5abbeca3e60ea7cf7abfa6f7f3 Maintainer: Manuel dG Status: ready -->
4+
<!-- splitted from ./index.xml, last change in rev 1.66 -->
5+
<chapter xml:id="security.cgi-bin" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
6+
<title>PHP installato come binario CGI</title>
7+
8+
<sect1 xml:id="security.cgi-bin.attacks">
9+
<title>Possibili attacchi</title>
10+
<simpara>
11+
L'utilizzo di PHP come binario <acronym>CGI</acronym> è un'opzione che ne permette l'uso se per qualche
12+
motivo non lo si voglia integrare come modulo del server (come Apache)
13+
sia per utilizzarlo con diversi tipi di wrapper <acronym>CGI</acronym> che per creare
14+
con <command>chroot</command> e <command>setuid</command> ambienti
15+
sicuri per gli script. Questa configurazione di solito prevede l'installazione
16+
del'eseguibile <command>php</command> nella directory del server web
17+
<filename class="directory">cgi-bin</filename>.
18+
L'informativa CERT <link xlink:href="&url.cert;">CA-96.11</link> sconsiglia
19+
di posizionare interpreti in <filename class="directory">cgi-bin</filename>.
20+
Invece il binario <command>php</command> può essere utilizzato in modo autonomo,
21+
PHP è progettato per prevenire gli attacchi possibili in questa configurazione:
22+
</simpara>
23+
<itemizedlist>
24+
<listitem>
25+
<simpara>
26+
Accesso al file system: <filename
27+
role="url">http://my.host/cgi-bin/php?/etc/passwd</filename>
28+
</simpara>
29+
<simpara>
30+
Le informazioni di una query ovvero la parte dell'URL dopo il punto interrogativo (<literal>?</literal>) vengono
31+
passate come argomenti dalla riga di comando dall'interfaccia CGI all'interprete.
32+
Di solito gli interpreti aprono ed eseguono il file
33+
specificato specificato nel primo argomento della riga di comando.
34+
</simpara>
35+
<simpara>
36+
Quando PHP viene invocato come binario CGI, <command>php</command> non interpreta
37+
gli argomenti della riga di comando.
38+
</simpara>
39+
</listitem>
40+
<listitem>
41+
<simpara>
42+
Accesso a qualsiasi documento web sul server:<filename
43+
role="url">http://my.host/cgi-bin/php/secret/doc.html</filename>
44+
</simpara>
45+
<simpara>
46+
Le informazioni sull'URL dopo il nome del binario PHP,
47+
<filename role="uri">/secret/doc.html</filename> sono
48+
convenzionalmente usate per specificare il nome dello script da
49+
aprire e interpretare dal programma <acronym>CGI</acronym>.
50+
Solitamente alcune direttive nella configurazione del server web (Apache:
51+
<literal>Action</literal>) sono usate per reindirizzare le richieste di documenti come
52+
<filename
53+
role="url">http://my.host/secret/script.php</filename> all'interprete PHP. Con questa configurazione,
54+
il server web prima controlla i permessi di accesso alla directory <filename
55+
role="uri">/secret</filename>, e poi crea la richiesta che viene reindirizzata a <filename
56+
role="url">http://my.host/cgi-bin/php/secret/script.php</filename>.
57+
Purtroppo, se la richiesta è fatta originariamente in questo modo,
58+
il server web non esegue alcun controllo di accesso al file <filename
59+
role="uri">/secret/script.php</filename>, ma solo per il file
60+
<filename role="uri">/cgi-bin/php</filename>. In questo modo
61+
qualsiasi utente che è in grado di accedere a <filename
62+
role="uri">/cgi-bin/php</filename> è in grado di accedere a qualsiasi
63+
documento protetto sul server web.
64+
</simpara>
65+
<simpara>
66+
In PHP, le direttive di configurazione a runtime <link
67+
linkend="ini.cgi.force-redirect">cgi.force_redirect</link>, <link
68+
linkend="ini.doc-root">doc_root</link> e <link
69+
linkend="ini.user-dir">user_dir</link> possono essere utilizzate per prevenire
70+
questo tipo di attacco, se la struttura dei documenti del server ha directory
71+
con restrizioni di accesso. Vedere qui di seguito per un completo chiarimento
72+
delle diverse combinazioni.
73+
</simpara>
74+
</listitem>
75+
</itemizedlist>
76+
</sect1>
77+
78+
<sect1 xml:id="security.cgi-bin.default">
79+
<title>1° Caso :solo files publici elaborati</title>
80+
81+
<simpara>
82+
Se il tuo server non ha alcun contenuto e non è protetto
83+
da password o un controllo d'accesso basato su IP, non c'è bisogno di
84+
questa configurazione. Se il tuo server web non ti consente
85+
di effettuare reindirizzamenti, o non hai un modo per
86+
comunicare all'eseguibile di PHP che la richiesta è una richiesta reindirizzata in modo sicuro, puoi abilitare la
87+
direttiva <link linkend="ini.cgi.force-redirect">cgi.force_redirect</link>.ini.
88+
Devi comunque assicurarti che i tuoi script PHP
89+
non usino nè un modo ne l'altro modo di chiamare lo script,
90+
né direttamente <filename
91+
role="php">http://my.host/cgi-bin/php/dir/script.php</filename>
92+
né tramite reindirizzamento <filename
93+
role="php">http://my.host/dir/script.php</filename>.
94+
</simpara>
95+
<simpara>
96+
Il reindirizzamento può essere configurato in Apache utilizzando <literal>AddHandler</literal> e la direttiva
97+
<literal>Action</literal> (vedi sotto).
98+
</simpara>
99+
</sect1>
100+
101+
<sect1 xml:id="security.cgi-bin.force-redirect">
102+
<title>2° Caso : utilizzo di <literal>cgi.force_redirect</literal></title>
103+
<simpara>
104+
La configurazione della direttiva <link
105+
linkend="ini.cgi.force-redirect">cgi.force_redirect</link>
106+
impedisce a chiunque di chiamare direttamente <command>php</command>
107+
tramite URL <filename
108+
role="php">http://my.host/cgi-bin/php/secretdir/script.php</filename>.
109+
Invece, PHP funzionerà in questa modalità solo se la richiesta viene fatta
110+
passare attraverso le regole di reindirizzamento del server web.
111+
</simpara>
112+
<simpara>
113+
Solitamente il reindirizzamento nella configurazione di Apache
114+
viene eseguito con le seguenti direttive:
115+
</simpara>
116+
<programlisting role="apache-conf">
117+
<![CDATA[
118+
Action php-script /cgi-bin/php
119+
AddHandler php-script .php
120+
]]>
121+
</programlisting>
122+
<simpara>
123+
Questa opzione è stata testata solo con il server web Apache
124+
e si basa su Apache per impostare la variabile di ambiente
125+
CGI non standard <envar>REDIRECT_STATUS</envar> sulle richieste
126+
reindirizzate. Se il server web non supporta alcun modo per
127+
stabilire se la richiesta è diretta o reindirizzata, non è
128+
possibile utilizzare questa opzione e si deve utilizzare uno
129+
degli altri modi per eseguire la versione CGI documentata
130+
qui.
131+
</simpara>
132+
</sect1>
133+
134+
<sect1 xml:id="security.cgi-bin.doc-root">
135+
<title>3°: impostare doc_root o user_dir</title>
136+
<simpara>
137+
Includere contenuti attivi, come script ed eseguibili, nelle
138+
directory dei documenti del server Web è talvolta considerato
139+
una pratica non sicura. Se, a causa di un errore di configurazione,
140+
gli script non vengono eseguiti ma visualizzati come normali documenti HTML,
141+
ciò può causare la perdita di proprietà intellettuale o far visualizare informazioni di
142+
sicurezza come le password. Pertanto, molti amministratori di sistema
143+
preferiranno impostare un'altra struttura di directory per gli script
144+
accessibili solo tramite PHP CGI e quindi saranno sempre interpretati e
145+
non visualizzati come tali.
146+
</simpara>
147+
<simpara>
148+
Inoltre, se il metodo per verificare che le richieste non vengano
149+
reindirizzate, come descritto nella sezione precedente, non è disponibile,
150+
è necessario impostare il <link linkend="ini.doc-root">doc_root</link> degli script
151+
diverso dalla radice dei documenti Web.
152+
</simpara>
153+
<simpara>
154+
Puoi impostare la directory per gli script di PHP tramite la direttiva di configurazione
155+
<link linkend="ini.doc-root">doc_root</link> nel
156+
<link linkend="configuration.file">file di configurazione</link>, oppure
157+
puoi impostare la variabile d'ambiente
158+
<envar>PHP_DOCUMENT_ROOT</envar>. Se è stata configurata, la versione <acronym>CGI</acronym>
159+
di PHP eseguirà sempre il file che si trova in
160+
<parameter>doc_root</parameter> con le informazioni sul percorso URL, così puoi essere sicuro
161+
che nessuno script venga eseguito al di fuori di questa
162+
directory (tranne per <parameter>user_dir</parameter>
163+
di seguito).
164+
</simpara>
165+
<simpara>
166+
Un'altra opzione utilizzabile è <link
167+
linkend="ini.user-dir">user_dir</link>. Quando <parameter>user_dir</parameter> non è
168+
impostato, l'unica cosa che controlla nel file aperto è
169+
<parameter>doc_root</parameter>. L'apertura di un URL come <filename
170+
role="url">http://my.host/~user/doc.php</filename> non
171+
comporta l'apertura di un file nella directory home dell'utente, ma di un file
172+
chiamato <filename role="uri">~user/doc.php</filename> in
173+
<parameter>doc_root</parameter> (esatto, il nome della directory inizia con una tilde
174+
[<literal>~</literal>]).
175+
</simpara>
176+
<simpara>
177+
Se la <parameter>user_dir</parameter> è impostata, ad esempio, su <filename
178+
role="dir">public_php</filename>, una richiesta come <filename
179+
role="url">http://my.host/~user/doc.php</filename> aprirà un file
180+
file chiamato <filename>doc.php</filename> nella directory
181+
denominata <filename role="dir">public_php</filename> sotto la home
182+
directory dell'utente. Se la home dell'utente è <filename
183+
role="dir">/home/user</filename>, il file eseguito è
184+
<filename>/home/user/public_php/doc.php</filename>.
185+
</simpara>
186+
<simpara>
187+
L'espansione <parameter>user_dir</parameter> avviene indipendentemente
188+
dall'impostazione <parameter>doc_root</parameter>, in modo da poter controllare
189+
la radice del documento e l'accesso alla directory dell'utente
190+
separatamente.
191+
</simpara>
192+
</sect1>
193+
194+
<sect1 xml:id="security.cgi-bin.shell">
195+
<title>4° Caso: script PHP fuori dalla cartella web</title>
196+
<para>
197+
Un'opzione molto sicura è mettere il binario del parser PHP da qualche parte
198+
al di fuori dell'cartella web dei file. In <filename
199+
role="dir">/usr/local/bin</filename>, per esempio. L'unico vero
200+
lo svantaggio di questa opzione è che ora dovrai inserire una riga
201+
simile a:
202+
<informalexample>
203+
<programlisting>
204+
<![CDATA[
205+
#!/usr/local/bin/php
206+
]]>
207+
</programlisting>
208+
</informalexample>
209+
come prima riga di qualsiasi file PHP deve contenere il tag. Avrai anche bisogno di
210+
rendere il file eseguibile. Dovrai fare esattamente come
211+
tratteresti qualsiasi altro script CGI script in Perl o sh o un'altro
212+
altro comune linguaggio di scripting che utilizza l'escape
213+
<literal>#!</literal> come meccanismo per avviarsi.
214+
</para>
215+
<para>
216+
Per far sì che PHP gestisca correttamente le informazioni <envar>PATH_INFO</envar> e
217+
<envar>PATH_TRANSLATED</envar> in modo corretto con questa configurazione, è necessario
218+
abilitare la direttiva <link linkend='ini.cgi.discard-path'>cgi.discard_path</link>.
219+
</para>
220+
</sect1>
221+
222+
</chapter>
223+
224+
<!-- Keep this comment at the end of the file
225+
Local variables:
226+
mode: sgml
227+
sgml-omittag:t
228+
sgml-shorttag:t
229+
sgml-minimize-attributes:nil
230+
sgml-always-quote-attributes:t
231+
sgml-indent-step:1
232+
sgml-indent-data:t
233+
indent-tabs-mode:nil
234+
sgml-parent-document:nil
235+
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
236+
sgml-exposed-tags:nil
237+
sgml-local-catalogs:nil
238+
sgml-local-ecat-files:nil
239+
End:
240+
vim600: syn=xml fen fdm=syntax fdl=2 si
241+
vim: et tw=78 syn=sgml
242+
vi: ts=1 sw=1
243+
-->

0 commit comments

Comments
 (0)