cvs: phpdoc /fr/chapters security.xml
| From: | Damien Seguy | Date: | Wed, 25 Jul 2001 19:13:42 +0000 |
| Subject: | cvs: phpdoc /fr/chapters security.xml | ||
| Groups: | php.doc | ||
| Request: | Send a blank email to phpdoc+get-969336497@lists.php.net to get a copy of this message | ||
dams Wed Jul 25 15:13:42 2001 EDT
Modified files:
/phpdoc/fr/chapters security.xml
Log:
Correcting some typos
Index: phpdoc/fr/chapters/security.xml diff -u phpdoc/fr/chapters/security.xml:1.15 phpdoc/fr/chapters/security.xml:1.16 --- phpdoc/fr/chapters/security.xml:1.15 Thu Mar 22 05:34:35 2001 +++ phpdoc/fr/chapters/security.xml Wed Jul 25 15:13:42 2001 @@ -1,41 +1,41 @@ <chapter id="security"> <title>Sécurité</title> <simpara> - PHP est un langage puissant et l'interpréteur, qu'il soit inclus dans le - serveur web ou bien compilé en version CGI, est capable d'accéder - aux fichiers, d'exécuter des commandes et d'ouvrir des connexions - réseaux. Toutes ces propriétés rendent fragile la - sécurité d'un serveur web. Le langage PHP a été - pensé afin d'être un langage beaucoup plus sécurisé - pour écrire des <acronym>CGI</acronym> que le Perl ou le langage C. De - plus une sélection rigoureuse des options de compilation et - d'exécution vous permettront d'obtenir un équilibre - parfait entre liberté et sécurité. + PHP est un langage puissant et l'interpréteur, qu'il soit inclus dans le + serveur web ou bien compilé en version CGI, est capable d'accéder + aux fichiers, d'exécuter des commandes et d'ouvrir des connexions + réseaux. Toutes ces propriétés rendent fragile la + sécurité d'un serveur web. Le langage PHP a été + pensé afin d'être un langage beaucoup plus sécurisé + pour écrire des <acronym>CGI</acronym> que le Perl ou le langage C. De + plus, une sélection rigoureuse des options de compilation et + d'exécution vous permettra d'obtenir un équilibre + parfait entre liberté et sécurité. </simpara> <simpara> - Etant donné qu'il y a de nombreux moyens d'utiliser le langage PHP, - il y a de nombreuses directives de configuration afin d'en contrôler - le comportement. Un grand nombre d'options permettent d'utiliser le PHP - dans de nombreuses situations, mais cela signifie aussi qu'il y a certaines - combinaisons d'options de compilation et d'exécution qui fragilise - la sécurité du serveur. Ce chapitre explique comme les - différentes options de configurations peuvent être - combinées, tout en conservant une sécurité maximum. + Etant donné qu'il y a de nombreux moyens d'utiliser le langage PHP, + il y a de nombreuses directives de configuration afin d'en contrôler + le comportement. Un grand nombre d'options permettent d'utiliser le PHP + dans de nombreuses situations, mais cela signifie aussi qu'il y a certaines + combinaisons d'options de compilation et d'exécution qui fragilisent + la sécurité du serveur. Ce chapitre explique comme les + différentes options de configurations peuvent être + combinées, tout en conservant une sécurité maximum. </simpara> <simpara> La flexibilité de configuration de PHP est épaulée par la flexibilité du code. PHP peut être compilé pour constituer une application serveur complète, avec toutes les fonctionnalités d'un shell, ou il peut encore - être utilisé comple simple SSI (server side include) + être utilisé comme simple SSI (server side include) avec peu de risque, dans un environnement à sécurité renforcée. Comment créer cet environnement et le - sécurisé est largement à la charge du + sécuriser est largement à la charge du développeur PHP. </simpara> <simpara> Ce chapitre commence par expliquer les différentes options de configuration - et les situations où elles peuvent être utilisées en + et les situations dans lesquelles elles peuvent être utilisées en toute sécurité. Puis, viennent les considérations de niveaux de sécurité, et les conseils généraux. </simpara> @@ -44,20 +44,20 @@ <sect2 id="security.cgi.attacks"> <title>Faiblesses connues</title> <simpara> - Utiliser le PHP comme un <acronym>CGI</acronym> exécutable vient - la plupart du temps du fait que l'on ne veut pas l'utiliser comme un module - du serveur web, (comme Apache), ou bien que l'on souhaite l'utiliser en - combinaison d'un <acronym>CGI</acronym> complémentaire, afin de - créer un environnement de script sécurisé (en utilisant - des techniques de chroot ou setuid). Une telle décision signifie - habituellement que vous installez votre exécutable dans le - répertoire cgi-bin de votre serveur web. - <ulink url="&url.cert;">CERT CA-96.11</ulink> recommande effectivement de - placer l'interpréteur à l'intérieur du répertoire - cgi-bin. Même si le binaire PHP peut être utilisé comme - interpréteur indépendant, PHP a été - pensé afin de rendre impossible les attaques que ce type - d'installation induit. + Utiliser le PHP comme un <acronym>CGI</acronym> exécutable vient + la majorité du temps du fait que l'on ne veut pas l'utiliser comme un module + du serveur web, (comme Apache), ou bien que l'on souhaite l'utiliser en + combinaison d'un <acronym>CGI</acronym> complémentaire, afin de + créer un environnement de script sécurisé (en utilisant + des techniques de chroot ou setuid). Une telle décision signifie + habituellement que vous installez votre exécutable dans le + répertoire cgi-bin de votre serveur web. + <ulink url="&url.cert;">CERT CA-96.11</ulink> recommande effectivement de + placer l'interpréteur à l'intérieur du répertoire + cgi-bin. Même si le binaire PHP peut être utilisé comme + interpréteur indépendant, PHP a été + pensé afin de rendre impossible les attaques que ce type + d'installation induit. </simpara> <itemizedlist> <listitem> @@ -66,15 +66,15 @@ <filename role="url">http://ma.machine/cgi-bin/php?/etc/passwd</filename> </simpara> <simpara> - Lorsque la requête est passée dans une url, après le point - d'interrogation (?), elle est envoyée à l'interpréteur - comme une ligne de commande par l'interface CGI. Habituellement, - l'interpréteur ouvre le fichier spécifié et - l'exécute. + Lorsque la requête est passée dans une url, après le point + d'interrogation (?), elle est envoyée à l'interpréteur + comme une ligne de commande par l'interface CGI. Habituellement, + l'interpréteur ouvre le fichier spécifié et + l'exécute. </simpara> <simpara> - Lorsqu'il est invoqué comme exécutable CGI, le PHP refuse - d'interpréter les arguments de la ligne de commande. + Lorsqu'il est invoqué comme exécutable CGI, le PHP refuse + d'interpréter les arguments de la ligne de commande. </simpara> </listitem> <listitem> @@ -83,26 +83,26 @@ <filename role="url">http://my.host/cgi-bin/php/secret/doc.html</filename> </simpara> <simpara> - Le "path information" dans l'url, situé juste après le nom - du binaire PHP, <filename role="uri">/secret/doc.html</filename> est - utilisé par convention pour spécifier le nom du fichier - qui doit être ouvert et interprété par le programe - <acronym>CGI</acronym>. Habituellement, des directives de configuration - du serveur web (pour le serveur Apache: Action) sont utilisées pour - rediriger les requêtes pour obtenir un document - <filename role="url">http://my.host/secret/script.php</filename> par - l'interpréteur PHP. Dans une telle configuration, le serveur web - vérifie d'abord si il a accès au répertoire - <filename role="uri">/secret</filename>, et après cette - vérification redirige la requête vers - <filename role="url">http://my.host/cgi-bin/php/secret/script.php</filename>. - Malheureusement, si la requête est faite directement sous cette forme, - aucune vérification d'accès n'est faite par le serveur web - pour le fichier <filename role="uri">/secret/script.php</filename>, - mais uniquement pour le fichier <filename role="uri">/cgi-bin/php</filename>. - De cette manière, n'importe quel utilisateur qui peut accéder - au fichier <filename role="uri">/cgi-bin/php</filename> peut aussi - accéder au document protégés sur le serveur web. + Le "path information" dans l'url, situé juste après le nom + du binaire PHP, <filename role="uri">/secret/doc.html</filename> est + utilisé par convention pour spécifier le nom du fichier + qui doit être ouvert et interprété par le programe + <acronym>CGI</acronym>. Habituellement, des directives de configuration + du serveur web (pour le serveur Apache: Action) sont utilisées pour + rediriger les requêtes afin d'obtenir un document + <filename role="url">http://my.host/secret/script.php</filename> par + l'interpréteur PHP. Dans une telle configuration, le serveur web + vérifie d'abord s'il a accès au répertoire + <filename role="uri">/secret</filename>, et après cette + vérification redirige la requête vers + <filename role="url">http://my.host/cgi-bin/php/secret/script.php</filename>. + Malheureusement, si la requête est faite directement sous cette forme, + aucune vérification d'accès n'est faite par le serveur web + pour le fichier <filename role="uri">/secret/script.php</filename>, + mais uniquement pour le fichier <filename role="uri">/cgi-bin/php</filename>. + De cette manière, n'importe quel utilisateur qui peut accéder + au fichier <filename role="uri">/cgi-bin/php</filename> peut aussi + accéder aux documents protégés sur le serveur web. </simpara> <simpara> Avec le PHP, l'option de compilation @@ -148,7 +148,7 @@ Cette option de compilation prévient quiconque d'appeler directement un script avec l'url <filename role="php">http://my.host/cgi-bin/php/secretdir/script.php</filename>. - Dans ce cas là, PHP parsera le fichier uniquement si il y a eu redirection. + Dans ce cas là, PHP parsera le fichier uniquement s'il y a eu redirection. </simpara> <simpara> Habituellement, le serveur web Apache réalise une redirection @@ -162,11 +162,11 @@ Cette option a uniquement été testée avec Apache et compte sur Apache pour affecter la variable d'environnement non-standart <envar>REDIRECT_STATUS</envar> pour les requêtes redirigées. - Dans le cas oú votre serveur web ne supporte pas le renseignement + Dans le cas où votre serveur web ne supporte pas le renseignement du PHP, pour savoir si la requête a été redirigée ou non, vous ne pouvez pas utiliser cette option de - compilation. Vous devez alors utiliser une des autres manières - pour utiliser la version binaire CGI du PHP, comme exposé ci-dessous. + compilation. Vous devez alors utiliser une des autres méthodes + d'exploitation de la version binaire CGI du PHP, comme exposé ci-dessous. </simpara> </sect2> <sect2 id="security.cgi.doc-root"> @@ -178,11 +178,11 @@ exécuté mais affiché comme une page HTML classique, il peut en résulter un vol de propriété intellectuelle ou des problèmes de sécurité à propos des mots - de passe notamment. Donc, la plupart des administrateurs + de passe notamment. Donc, la majorité des administrateurs préfèrent mettre en place un répertoire - spécial pour les scripts qui est uniquement accessible par le biais + spécial pour les scripts qui soit uniquement accessible par le biais du binaire CGI du PHP, et donc, tous les fichiers de ce répertoire - seront interprétés et non affichés tels quel. + seront interprétés et non affichés tels quels. </simpara> <simpara> Aussi, si vous ne pouvez pas utiliser la méthode @@ -199,14 +199,14 @@ toujours le nom de fichier à ouvrir avec <parameter>doc_root</parameter> et le "path information" de la requête, et donc vous serez sûr qu'aucun script n'est exécuté en dehors du répertoire - prédéfinit. (à l'exception du répertoire + prédéfini (à l'exception du répertoire désigné par la directive <parameter>user_dir</parameter> Voir ci-dessous). </simpara> <simpara> Une autre option possible ici est la directive <link linkend="ini.user-dir">user_dir</link>. Lorsque la directive n'est pas - activée, seulement les fichiers contenues dans le répertoire + activée, seuls les fichiers contenus dans le répertoire <parameter>doc_root</parameter> peuvent être ouverts. Ouvrir un fichier possédant l'url <filename role="url">http://my.host/~user/doc.php</filename> ne correspond @@ -270,22 +270,22 @@ <simpara> Lorsque le PHP est compilé en tant que module Apache, ce module hérite des permissions accordées à l'utilisateur - faisant tourner Apache ( par défaut, l'utilisateur "noboby"). + faisant tourner Apache ( par défaut, l'utilisateur "nobody"). Par exemple, si vous utilisez PHP pour accéder à une - base de données à moins que la base n'ai un + base de données, à moins que la base n'ait un système de droits d'accès interne, vous devrez rendre la base accessible à l'utilisateur "nobody". Cela signifie - qu'un script malintentionné peut accéder à la base, + qu'un script mal intentionné peut accéder à la base, la modifier sans authentification. Il est aussi possible qu'un - robot accéde à la page d'administration, et - détruise toutes les pages. Vous devez ainsi protéger + robot accède à la page d'administration, et + détruise toutes les pages. Vous devez aussi protéger vos bases de données avec les autorisations Apache, ou définir votre propre modèle d'accès avec - LDAP, .htaccess, etc... et include ce code dans tous vos scripts + LDAP, .htaccess, etc... et inclure ce code dans tous vos scripts PHP. </simpara> <simpara> - Souvent, lorsqu'on a établit les droits pour que l'utilisateur + Souvent, lorsqu'on a établi les droits de l'utilisateur PHP (ici, l'utilisateur Apache) pour minimiser les risques, on s'aperçoit que PHP ne peut plus écrire des virus dans les fichiers des utilisateurs. Ou encore, de modifier une base @@ -299,27 +299,28 @@ </simpara> <simpara> Donner de telles permissions à l'utilisateur Apache est extrêmement - dangereux, et peut compromettre tout le système, tell que l'utilisation - des sudo ou du chroot. Une telle utilisation est à exclure pour les - profesionnels de la sécurité. + dangereux, et peut compromettre tout le système, telle que l'utilisation + des <literal>sudo</literal> ou du <literal>chroot</literal>. + Pour les professionnels de la sécurité, une telle utilisation + est à exclure d'office. </simpara> </sect1> <sect1 id="security.filesystem"> <title>Sécurité des fichiers</title> <simpara> - PHP est soumis aux règles de sécurité - intrinsèques de la plus part des systèmes serveurs : - il respecte notamment les droits des fichiers, et des dossiers. - Une attention particulière doit être portée aux - fichiers qui sont accessible à tout le monde, afin de - s'assurer qu'ils ne divulguent pas d'informations critiques. + PHP est soumis aux règles de sécurité + intrinsèques de la plupart des systèmes serveurs : + il respecte notamment les droits des fichiers et des dossiers. + Une attention particulière doit être portée aux + fichiers ou dossiers qui sont accessibles à tout le monde, afin de + s'assurer qu'ils ne divulguent pas d'informations critiques. </simpara> <simpara> Puisque PHP a été fait pour permettre aux utilisateurs d'accéder aux fichiers, il est possible de créer un script qui vous permet de lire des fichiers tels que /etc/password, de modifier les connexions ethernet, lancer des impressions de documents, - etc... Cela implique notamment que vous devez vous assurer que les fichiers + etc... Cela implique notamment que vous devez-vous assurer que les fichiers accédés par les scripts sont bien ceux qu'il faut. </simpara> <simpara> @@ -332,7 +333,7 @@ </simpara> <para> <example> - <title>Une erreur de vérification de variable conduit à ....</title> + <title>Une erreur de vérification de variable conduit à ...</title> <programlisting role="php"> <?php // efface un fichier dans un dossier racine @@ -344,15 +345,15 @@ ?> </programlisting> </example> - Etant donné que le nom de l'utilisateur est à fournir, ils peuvent - envoyer un nom d'utilisateur autre que le leur, et effacer des - documents dans les comptes des autres utilisateurs. - Dans ce cas, vous souhaiterez utiliser une autre forme d'authentification. - Considérez ce qui pourrait se passer si les utilisateurs passer - "../etc/" et "passwd" comme arguments!. Le code serait éxécuté - tel que : + Etant donné que le nom de l'utilisateur est à fournir, des intrus peuvent + envoyer un nom d'utilisateur autre que le leur, et effacer des + documents dans les comptes des autres utilisateurs. + Dans ce cas, vous souhaiterez utiliser une autre forme d'authentification. + Considérez ce qui pourrait se passer si les utilisateurs passent + "../etc/" et "passwd" comme arguments! Le code serait éxécuté + tel que : <example> - <title>Une attaque du système de fichier!</title> + <title>Une attaque du système de fichiers!</title> <programlisting role="php"> <?php // efface un fichier n'importe où sur le disque dur, @@ -376,7 +377,7 @@ <listitem> <simpara> Vérifier toutes les variables liées aux chemins et aux fichiers - qui sont fournies. + qui sont fournie. </simpara> </listitem> </itemizedlist> @@ -385,7 +386,7 @@ <title>Une vérification renforcée</title> <programlisting role="php"> <?php -// Efface un fichier sur le disque où l'utilisateur à le droit +// Efface un fichier sur le disque où l'utilisateur à le droit d'aller $username = get_env("REMOTE_USER"); // utilise un mécanisme d'authentification $homedir = "/home/$username"; @@ -400,9 +401,9 @@ ?> </programlisting> </example> - Vous pouvez vous protéger avec une vérification telle que : + Vous pouvez-vous protéger avec une vérification telle que : <example> - <title>Vérfication de noms de fichier sécurisée</title> + <title>Vérification de noms de fichier sécurisée</title> <programlisting role="php"> <?php $username = $HTTP_REMOTE_USER; @@ -426,13 +427,13 @@ <simpara> Une tactique d'attaque standard consiste à faire faire des erreurs au système, et lire les variables d'environnement et de contexte qui - sont retournées. Cela permet au hacker de lire de nombreuses - informations sur le serveur, et détecter des faiblesses du serveur. + sont retournées. Cela permet au pirate de lire de nombreuses + informations sur le serveur, et de détecter des faiblesses du serveur. </simpara> <simpara> Les erreurs PHP qui sont normalement retournées peuvent être très pratiques pour un développeur qui essaie de débugger un - scripts, car elles donnent de précieux renseignements tels que + script, car elles donnent de précieux renseignements tels que quelle fonction a échoué, quel fichier n'a pas été trouvé, quel script PHP a buggé, et quelle ligne est en faute. Toutes ces informations sont exploitables. Il est commun aux développeurs PHP @@ -440,7 +441,7 @@ <function>highlight_string</function>, ou <function>highlight_file</function> comme outils de débuggage, mais sur un site en production, cela expose des variables cachées, des syntaxes non vérifiées - ou d'autres informations dangeureuses. + ou d'autres informations dangereuses. </simpara> <simpara> Par exemple, le style d'erreur indique sur quel système PHP fonctionne. @@ -454,9 +455,9 @@ été générée. Cela peut orienter l'intrus vers les ports de cette base de données ou bien vers une attaque liée à cette application. En envoyant des données - érronées, par exemple, un pirate peut déterminer l'ordre + erronées, par exemple, un pirate peut déterminer l'ordre d'authentification dans un script (à partir des lignes d'erreurs), - et essayer de les exploiter ailleurs, dans le script. + et d'essayer de les exploiter ailleurs, dans le script. </simpara> <simpara> Une erreur de fichier, ou une erreur générale PHP peut indiquer @@ -476,7 +477,7 @@ </simpara> </sect1> <sect1 id="security.variables"> - <title>User Submitted Data</title> + <title>Données transmises par les internautes</title> <para> Les plus grandes faiblesses de nombreux programmes PHP ne viennent pas du langage lui-même, mais de son utilisation en omettant les @@ -499,42 +500,42 @@ ?> </programlisting> </example> - Il est vivement recommandé d'éxaminer minutieusement votre code + Il est vivement recommandé d'examiner minutieusement votre code pour vous assurer qu'il n'y a pas de variables envoyées par le - client web, et qui ne sont pas suffisament vérifiée avant utilisation. + client web, et qui ne sont pas suffisamment vérifiées avant utilisation. <itemizedlist> <listitem> <simpara> - Est ce que ce script n'affectera que les fichiers prévus? + Est-ce que ce script n'affectera que les fichiers prévus? </simpara> </listitem> <listitem> <simpara> - Est il possible que des valeurs incohérentes soient exploitées ici? + Est-il possible que des valeurs incohérentes soient exploitées ici? </simpara> </listitem> <listitem> <simpara> - Est ce que ce script peut être utilisé dans un but différents? + Est-ce que ce script peut être utilisé dans un but différent? </simpara> </listitem> <listitem> <simpara> - Est ce que ce script peut être utilisé malicieusement, + Est-ce que ce script peut être utilisé malicieusement, en conjonction avec d'autres? </simpara> </listitem> <listitem> <simpara> - Est ce que toutes les actions seront notées? + Est-ce que toutes les actions seront notées? </simpara> </listitem> </itemizedlist> En répondant de manière adéquate à ces questions lors de l'écriture de vos scripts (plutôt qu'après), vous éviterez une réécriture inopportune pour raison de - sécurité. En commencant vos projets avec ces recommandations - en têtes, vous garantirez pas la sécurité de votre + sécurité. En commençant vos projets avec ces recommandations + en tête, vous ne garantirez pas la sécurité de votre système, mais vous contribuerez à l'améliorer. </para> <para> @@ -558,7 +559,7 @@ nécessitaient deux formes d'identification biométriques (comme par exemple un scanner de la rétine, et une empreinte digitale), vous pourriez avoir un niveau de - sécurité élevé. Cela prendrai aussi + sécurité élevé. Cela prendrait aussi une demi-heure pour remplir les conditions de sécurité, ce qui pousserait les utilisateurs à éviter d'utiliser votre système. @@ -573,10 +574,10 @@ <simpara> Une phrase qui vaut la peine d'être retenue : un système est aussi fiable que son maillon le plus faible. Si toutes les - transactions sont exhaustivement noté (heure, lieu, type, etc...) + transactions sont exhaustivement notées (heure, lieu, type, etc...) mais que l'utilisateur n'est authentifié que par un cookie, la validité de votre système de surveillance est intimement - lié à la validité du cookie (et donc, + liée à la validité du cookie (et donc, sévèrement réduite). </simpara> <simpara> @@ -584,20 +585,20 @@ tester toutes les configurations, mais probablement les plus simples. Les données en entrées auxquelles vous pouvez vous attendre ne seront rien comparées aux données - incohérentes qu'un employé négligent, un - hacker disposant d'autant de temps qu'il veut, ou du chat de la + incohérentes d'un employé négligent, un + pirate disposant d'autant de temps qu'il veut, ou du chat de la maison marchant sur le clavier. Il est donc bon de regarder le - code logiquement, de voir d'où des données incohérentes + code logiquement, de chercher où des données incohérentes peuvent être introduites, modifiées, réduites ou amplifiées. </simpara> <simpara> L'Internet est rempli de personnes qui tentent de se faire une renommée - en piratant vos programmes, bloquant votre site, envoyant des contenus + en piratant vos programmes, en bloquant votre site, en envoyant des contenus inappropriés, qui rendent vos journées si "spéciales". Peut importe que vous ayez un grand portail ou un petit web, vous pouvez être la cible pour tout quidam avec une connexion. Vous êtes une - cible potentielle dès que vous êtes connecté vous même. + cible potentielle dès que vous êtes connecté vous-même. Certains programmes de piratage ne font pas dans la demi-mesure, et testent systématiquement des millions d'IP, à la recherche de victimes : ne soyez pas la prochaine. @@ -606,10 +607,10 @@ <sect1 id="security.current"> <title>Etre à jour</title> <simpara> - PHP, comme de nombreux systèmes de grandes tailles, est constamment + PHP, comme de nombreux systèmes de grande taille, est constamment testé et amélioré. Chaque nouvelle version rassemble des modifications majeures et mineures, aussi bien pour renforcer la - sécurité, réparer les problèmes de conceptions + sécurité, que pour réparer les problèmes de conceptions de configuration, et d'autres points qui peuvent affecter la sécurité globale et la stabilité de votre système. </simpara>
Index: phpdoc/fr/chapters/security.xml diff -u phpdoc/fr/chapters/security.xml:1.15 phpdoc/fr/chapters/security.xml:1.16 --- phpdoc/fr/chapters/security.xml:1.15 Thu Mar 22 05:34:35 2001 +++ phpdoc/fr/chapters/security.xml Wed Jul 25 15:13:42 2001 @@ -1,41 +1,41 @@ <chapter id="security"> <title>Sécurité</title> <simpara> - PHP est un langage puissant et l'interpréteur, qu'il soit inclus dans le - serveur web ou bien compilé en version CGI, est capable d'accéder - aux fichiers, d'exécuter des commandes et d'ouvrir des connexions - réseaux. Toutes ces propriétés rendent fragile la - sécurité d'un serveur web. Le langage PHP a été - pensé afin d'être un langage beaucoup plus sécurisé - pour écrire des <acronym>CGI</acronym> que le Perl ou le langage C. De - plus une sélection rigoureuse des options de compilation et - d'exécution vous permettront d'obtenir un équilibre - parfait entre liberté et sécurité. + PHP est un langage puissant et l'interpréteur, qu'il soit inclus dans le + serveur web ou bien compilé en version CGI, est capable d'accéder + aux fichiers, d'exécuter des commandes et d'ouvrir des connexions + réseaux. Toutes ces propriétés rendent fragile la + sécurité d'un serveur web. Le langage PHP a été + pensé afin d'être un langage beaucoup plus sécurisé + pour écrire des <acronym>CGI</acronym> que le Perl ou le langage C. De + plus, une sélection rigoureuse des options de compilation et + d'exécution vous permettra d'obtenir un équilibre + parfait entre liberté et sécurité. </simpara> <simpara> - Etant donné qu'il y a de nombreux moyens d'utiliser le langage PHP, - il y a de nombreuses directives de configuration afin d'en contrôler - le comportement. Un grand nombre d'options permettent d'utiliser le PHP - dans de nombreuses situations, mais cela signifie aussi qu'il y a certaines - combinaisons d'options de compilation et d'exécution qui fragilise - la sécurité du serveur. Ce chapitre explique comme les - différentes options de configurations peuvent être - combinées, tout en conservant une sécurité maximum. + Etant donné qu'il y a de nombreux moyens d'utiliser le langage PHP, + il y a de nombreuses directives de configuration afin d'en contrôler + le comportement. Un grand nombre d'options permettent d'utiliser le PHP + dans de nombreuses situations, mais cela signifie aussi qu'il y a certaines + combinaisons d'options de compilation et d'exécution qui fragilisent + la sécurité du serveur. Ce chapitre explique comme les + différentes options de configurations peuvent être + combinées, tout en conservant une sécurité maximum. </simpara> <simpara> La flexibilité de configuration de PHP est épaulée par la flexibilité du code. PHP peut être compilé pour constituer une application serveur complète, avec toutes les fonctionnalités d'un shell, ou il peut encore - être utilisé comple simple SSI (server side include) + être utilisé comme simple SSI (server side include) avec peu de risque, dans un environnement à sécurité renforcée. Comment créer cet environnement et le - sécurisé est largement à la charge du + sécuriser est largement à la charge du développeur PHP. </simpara> <simpara> Ce chapitre commence par expliquer les différentes options de configuration - et les situations où elles peuvent être utilisées en + et les situations dans lesquelles elles peuvent être utilisées en toute sécurité. Puis, viennent les considérations de niveaux de sécurité, et les conseils généraux. </simpara> @@ -44,20 +44,20 @@ <sect2 id="security.cgi.attacks"> <title>Faiblesses connues</title> <simpara> - Utiliser le PHP comme un <acronym>CGI</acronym> exécutable vient - la plupart du temps du fait que l'on ne veut pas l'utiliser comme un module - du serveur web, (comme Apache), ou bien que l'on souhaite l'utiliser en - combinaison d'un <acronym>CGI</acronym> complémentaire, afin de - créer un environnement de script sécurisé (en utilisant - des techniques de chroot ou setuid). Une telle décision signifie - habituellement que vous installez votre exécutable dans le - répertoire cgi-bin de votre serveur web. - <ulink url="&url.cert;">CERT CA-96.11</ulink> recommande effectivement de - placer l'interpréteur à l'intérieur du répertoire - cgi-bin. Même si le binaire PHP peut être utilisé comme - interpréteur indépendant, PHP a été - pensé afin de rendre impossible les attaques que ce type - d'installation induit. + Utiliser le PHP comme un <acronym>CGI</acronym> exécutable vient + la majorité du temps du fait que l'on ne veut pas l'utiliser comme un module + du serveur web, (comme Apache), ou bien que l'on souhaite l'utiliser en + combinaison d'un <acronym>CGI</acronym> complémentaire, afin de + créer un environnement de script sécurisé (en utilisant + des techniques de chroot ou setuid). Une telle décision signifie + habituellement que vous installez votre exécutable dans le + répertoire cgi-bin de votre serveur web. + <ulink url="&url.cert;">CERT CA-96.11</ulink> recommande effectivement de + placer l'interpréteur à l'intérieur du répertoire + cgi-bin. Même si le binaire PHP peut être utilisé comme + interpréteur indépendant, PHP a été + pensé afin de rendre impossible les attaques que ce type + d'installation induit. </simpara> <itemizedlist> <listitem> @@ -66,15 +66,15 @@ <filename role="url">http://ma.machine/cgi-bin/php?/etc/passwd</filename> </simpara> <simpara> - Lorsque la requête est passée dans une url, après le point - d'interrogation (?), elle est envoyée à l'interpréteur - comme une ligne de commande par l'interface CGI. Habituellement, - l'interpréteur ouvre le fichier spécifié et - l'exécute. + Lorsque la requête est passée dans une url, après le point + d'interrogation (?), elle est envoyée à l'interpréteur + comme une ligne de commande par l'interface CGI. Habituellement, + l'interpréteur ouvre le fichier spécifié et + l'exécute. </simpara> <simpara> - Lorsqu'il est invoqué comme exécutable CGI, le PHP refuse - d'interpréter les arguments de la ligne de commande. + Lorsqu'il est invoqué comme exécutable CGI, le PHP refuse + d'interpréter les arguments de la ligne de commande. </simpara> </listitem> <listitem> @@ -83,26 +83,26 @@ <filename role="url">http://my.host/cgi-bin/php/secret/doc.html</filename> </simpara> <simpara> - Le "path information" dans l'url, situé juste après le nom - du binaire PHP, <filename role="uri">/secret/doc.html</filename> est - utilisé par convention pour spécifier le nom du fichier - qui doit être ouvert et interprété par le programe - <acronym>CGI</acronym>. Habituellement, des directives de configuration - du serveur web (pour le serveur Apache: Action) sont utilisées pour - rediriger les requêtes pour obtenir un document - <filename role="url">http://my.host/secret/script.php</filename> par - l'interpréteur PHP. Dans une telle configuration, le serveur web - vérifie d'abord si il a accès au répertoire - <filename role="uri">/secret</filename>, et après cette - vérification redirige la requête vers - <filename role="url">http://my.host/cgi-bin/php/secret/script.php</filename>. - Malheureusement, si la requête est faite directement sous cette forme, - aucune vérification d'accès n'est faite par le serveur web - pour le fichier <filename role="uri">/secret/script.php</filename>, - mais uniquement pour le fichier <filename role="uri">/cgi-bin/php</filename>. - De cette manière, n'importe quel utilisateur qui peut accéder - au fichier <filename role="uri">/cgi-bin/php</filename> peut aussi - accéder au document protégés sur le serveur web. + Le "path information" dans l'url, situé juste après le nom + du binaire PHP, <filename role="uri">/secret/doc.html</filename> est + utilisé par convention pour spécifier le nom du fichier + qui doit être ouvert et interprété par le programe + <acronym>CGI</acronym>. Habituellement, des directives de configuration + du serveur web (pour le serveur Apache: Action) sont utilisées pour + rediriger les requêtes afin d'obtenir un document + <filename role="url">http://my.host/secret/script.php</filename> par + l'interpréteur PHP. Dans une telle configuration, le serveur web + vérifie d'abord s'il a accès au répertoire + <filename role="uri">/secret</filename>, et après cette + vérification redirige la requête vers + <filename role="url">http://my.host/cgi-bin/php/secret/script.php</filename>. + Malheureusement, si la requête est faite directement sous cette forme, + aucune vérification d'accès n'est faite par le serveur web + pour le fichier <filename role="uri">/secret/script.php</filename>, + mais uniquement pour le fichier <filename role="uri">/cgi-bin/php</filename>. + De cette manière, n'importe quel utilisateur qui peut accéder + au fichier <filename role="uri">/cgi-bin/php</filename> peut aussi + accéder aux documents protégés sur le serveur web. </simpara> <simpara> Avec le PHP, l'option de compilation @@ -148,7 +148,7 @@ Cette option de compilation prévient quiconque d'appeler directement un script avec l'url <filename role="php">http://my.host/cgi-bin/php/secretdir/script.php</filename>. - Dans ce cas là, PHP parsera le fichier uniquement si il y a eu redirection. + Dans ce cas là, PHP parsera le fichier uniquement s'il y a eu redirection. </simpara> <simpara> Habituellement, le serveur web Apache réalise une redirection @@ -162,11 +162,11 @@ Cette option a uniquement été testée avec Apache et compte sur Apache pour affecter la variable d'environnement non-standart <envar>REDIRECT_STATUS</envar> pour les requêtes redirigées. - Dans le cas oú votre serveur web ne supporte pas le renseignement + Dans le cas où votre serveur web ne supporte pas le renseignement du PHP, pour savoir si la requête a été redirigée ou non, vous ne pouvez pas utiliser cette option de - compilation. Vous devez alors utiliser une des autres manières - pour utiliser la version binaire CGI du PHP, comme exposé ci-dessous. + compilation. Vous devez alors utiliser une des autres méthodes + d'exploitation de la version binaire CGI du PHP, comme exposé ci-dessous. </simpara> </sect2> <sect2 id="security.cgi.doc-root"> @@ -178,11 +178,11 @@ exécuté mais affiché comme une page HTML classique, il peut en résulter un vol de propriété intellectuelle ou des problèmes de sécurité à propos des mots - de passe notamment. Donc, la plupart des administrateurs + de passe notamment. Donc, la majorité des administrateurs préfèrent mettre en place un répertoire - spécial pour les scripts qui est uniquement accessible par le biais + spécial pour les scripts qui soit uniquement accessible par le biais du binaire CGI du PHP, et donc, tous les fichiers de ce répertoire - seront interprétés et non affichés tels quel. + seront interprétés et non affichés tels quels. </simpara> <simpara> Aussi, si vous ne pouvez pas utiliser la méthode @@ -199,14 +199,14 @@ toujours le nom de fichier à ouvrir avec <parameter>doc_root</parameter> et le "path information" de la requête, et donc vous serez sûr qu'aucun script n'est exécuté en dehors du répertoire - prédéfinit. (à l'exception du répertoire + prédéfini (à l'exception du répertoire désigné par la directive <parameter>user_dir</parameter> Voir ci-dessous). </simpara> <simpara> Une autre option possible ici est la directive <link linkend="ini.user-dir">user_dir</link>. Lorsque la directive n'est pas - activée, seulement les fichiers contenues dans le répertoire + activée, seuls les fichiers contenus dans le répertoire <parameter>doc_root</parameter> peuvent être ouverts. Ouvrir un fichier possédant l'url <filename role="url">http://my.host/~user/doc.php</filename> ne correspond @@ -270,22 +270,22 @@ <simpara> Lorsque le PHP est compilé en tant que module Apache, ce module hérite des permissions accordées à l'utilisateur - faisant tourner Apache ( par défaut, l'utilisateur "noboby"). + faisant tourner Apache ( par défaut, l'utilisateur "nobody"). Par exemple, si vous utilisez PHP pour accéder à une - base de données à moins que la base n'ai un + base de données, à moins que la base n'ait un système de droits d'accès interne, vous devrez rendre la base accessible à l'utilisateur "nobody". Cela signifie - qu'un script malintentionné peut accéder à la base, + qu'un script mal intentionné peut accéder à la base, la modifier sans authentification. Il est aussi possible qu'un - robot accéde à la page d'administration, et - détruise toutes les pages. Vous devez ainsi protéger + robot accède à la page d'administration, et + détruise toutes les pages. Vous devez aussi protéger vos bases de données avec les autorisations Apache, ou définir votre propre modèle d'accès avec - LDAP, .htaccess, etc... et include ce code dans tous vos scripts + LDAP, .htaccess, etc... et inclure ce code dans tous vos scripts PHP. </simpara> <simpara> - Souvent, lorsqu'on a établit les droits pour que l'utilisateur + Souvent, lorsqu'on a établi les droits de l'utilisateur PHP (ici, l'utilisateur Apache) pour minimiser les risques, on s'aperçoit que PHP ne peut plus écrire des virus dans les fichiers des utilisateurs. Ou encore, de modifier une base @@ -299,27 +299,28 @@ </simpara> <simpara> Donner de telles permissions à l'utilisateur Apache est extrêmement - dangereux, et peut compromettre tout le système, tell que l'utilisation - des sudo ou du chroot. Une telle utilisation est à exclure pour les - profesionnels de la sécurité. + dangereux, et peut compromettre tout le système, telle que l'utilisation + des <literal>sudo</literal> ou du <literal>chroot</literal>. + Pour les professionnels de la sécurité, une telle utilisation + est à exclure d'office. </simpara> </sect1> <sect1 id="security.filesystem"> <title>Sécurité des fichiers</title> <simpara> - PHP est soumis aux règles de sécurité - intrinsèques de la plus part des systèmes serveurs : - il respecte notamment les droits des fichiers, et des dossiers. - Une attention particulière doit être portée aux - fichiers qui sont accessible à tout le monde, afin de - s'assurer qu'ils ne divulguent pas d'informations critiques. + PHP est soumis aux règles de sécurité + intrinsèques de la plupart des systèmes serveurs : + il respecte notamment les droits des fichiers et des dossiers. + Une attention particulière doit être portée aux + fichiers ou dossiers qui sont accessibles à tout le monde, afin de + s'assurer qu'ils ne divulguent pas d'informations critiques. </simpara> <simpara> Puisque PHP a été fait pour permettre aux utilisateurs d'accéder aux fichiers, il est possible de créer un script qui vous permet de lire des fichiers tels que /etc/password, de modifier les connexions ethernet, lancer des impressions de documents, - etc... Cela implique notamment que vous devez vous assurer que les fichiers + etc... Cela implique notamment que vous devez-vous assurer que les fichiers accédés par les scripts sont bien ceux qu'il faut. </simpara> <simpara> @@ -332,7 +333,7 @@ </simpara> <para> <example> - <title>Une erreur de vérification de variable conduit à ....</title> + <title>Une erreur de vérification de variable conduit à ...</title> <programlisting role="php"> <?php // efface un fichier dans un dossier racine @@ -344,15 +345,15 @@ ?> </programlisting> </example> - Etant donné que le nom de l'utilisateur est à fournir, ils peuvent - envoyer un nom d'utilisateur autre que le leur, et effacer des - documents dans les comptes des autres utilisateurs. - Dans ce cas, vous souhaiterez utiliser une autre forme d'authentification. - Considérez ce qui pourrait se passer si les utilisateurs passer - "../etc/" et "passwd" comme arguments!. Le code serait éxécuté - tel que : + Etant donné que le nom de l'utilisateur est à fournir, des intrus peuvent + envoyer un nom d'utilisateur autre que le leur, et effacer des + documents dans les comptes des autres utilisateurs. + Dans ce cas, vous souhaiterez utiliser une autre forme d'authentification. + Considérez ce qui pourrait se passer si les utilisateurs passent + "../etc/" et "passwd" comme arguments! Le code serait éxécuté + tel que : <example> - <title>Une attaque du système de fichier!</title> + <title>Une attaque du système de fichiers!</title> <programlisting role="php"> <?php // efface un fichier n'importe où sur le disque dur, @@ -376,7 +377,7 @@ <listitem> <simpara> Vérifier toutes les variables liées aux chemins et aux fichiers - qui sont fournies. + qui sont fournie. </simpara> </listitem> </itemizedlist> @@ -385,7 +386,7 @@ <title>Une vérification renforcée</title> <programlisting role="php"> <?php -// Efface un fichier sur le disque où l'utilisateur à le droit +// Efface un fichier sur le disque où l'utilisateur à le droit d'aller $username = get_env("REMOTE_USER"); // utilise un mécanisme d'authentification $homedir = "/home/$username"; @@ -400,9 +401,9 @@ ?> </programlisting> </example> - Vous pouvez vous protéger avec une vérification telle que : + Vous pouvez-vous protéger avec une vérification telle que : <example> - <title>Vérfication de noms de fichier sécurisée</title> + <title>Vérification de noms de fichier sécurisée</title> <programlisting role="php"> <?php $username = $HTTP_REMOTE_USER; @@ -426,13 +427,13 @@ <simpara> Une tactique d'attaque standard consiste à faire faire des erreurs au système, et lire les variables d'environnement et de contexte qui - sont retournées. Cela permet au hacker de lire de nombreuses - informations sur le serveur, et détecter des faiblesses du serveur. + sont retournées. Cela permet au pirate de lire de nombreuses + informations sur le serveur, et de détecter des faiblesses du serveur. </simpara> <simpara> Les erreurs PHP qui sont normalement retournées peuvent être très pratiques pour un développeur qui essaie de débugger un - scripts, car elles donnent de précieux renseignements tels que + script, car elles donnent de précieux renseignements tels que quelle fonction a échoué, quel fichier n'a pas été trouvé, quel script PHP a buggé, et quelle ligne est en faute. Toutes ces informations sont exploitables. Il est commun aux développeurs PHP @@ -440,7 +441,7 @@ <function>highlight_string</function>, ou <function>highlight_file</function> comme outils de débuggage, mais sur un site en production, cela expose des variables cachées, des syntaxes non vérifiées - ou d'autres informations dangeureuses. + ou d'autres informations dangereuses. </simpara> <simpara> Par exemple, le style d'erreur indique sur quel système PHP fonctionne. @@ -454,9 +455,9 @@ été générée. Cela peut orienter l'intrus vers les ports de cette base de données ou bien vers une attaque liée à cette application. En envoyant des données - érronées, par exemple, un pirate peut déterminer l'ordre + erronées, par exemple, un pirate peut déterminer l'ordre d'authentification dans un script (à partir des lignes d'erreurs), - et essayer de les exploiter ailleurs, dans le script. + et d'essayer de les exploiter ailleurs, dans le script. </simpara> <simpara> Une erreur de fichier, ou une erreur générale PHP peut indiquer @@ -476,7 +477,7 @@ </simpara> </sect1> <sect1 id="security.variables"> - <title>User Submitted Data</title> + <title>Données transmises par les internautes</title> <para> Les plus grandes faiblesses de nombreux programmes PHP ne viennent pas du langage lui-même, mais de son utilisation en omettant les @@ -499,42 +500,42 @@ ?> </programlisting> </example> - Il est vivement recommandé d'éxaminer minutieusement votre code + Il est vivement recommandé d'examiner minutieusement votre code pour vous assurer qu'il n'y a pas de variables envoyées par le - client web, et qui ne sont pas suffisament vérifiée avant utilisation. + client web, et qui ne sont pas suffisamment vérifiées avant utilisation. <itemizedlist> <listitem> <simpara> - Est ce que ce script n'affectera que les fichiers prévus? + Est-ce que ce script n'affectera que les fichiers prévus? </simpara> </listitem> <listitem> <simpara> - Est il possible que des valeurs incohérentes soient exploitées ici? + Est-il possible que des valeurs incohérentes soient exploitées ici? </simpara> </listitem> <listitem> <simpara> - Est ce que ce script peut être utilisé dans un but différents? + Est-ce que ce script peut être utilisé dans un but différent? </simpara> </listitem> <listitem> <simpara> - Est ce que ce script peut être utilisé malicieusement, + Est-ce que ce script peut être utilisé malicieusement, en conjonction avec d'autres? </simpara> </listitem> <listitem> <simpara> - Est ce que toutes les actions seront notées? + Est-ce que toutes les actions seront notées? </simpara> </listitem> </itemizedlist> En répondant de manière adéquate à ces questions lors de l'écriture de vos scripts (plutôt qu'après), vous éviterez une réécriture inopportune pour raison de - sécurité. En commencant vos projets avec ces recommandations - en têtes, vous garantirez pas la sécurité de votre + sécurité. En commençant vos projets avec ces recommandations + en tête, vous ne garantirez pas la sécurité de votre système, mais vous contribuerez à l'améliorer. </para> <para> @@ -558,7 +559,7 @@ nécessitaient deux formes d'identification biométriques (comme par exemple un scanner de la rétine, et une empreinte digitale), vous pourriez avoir un niveau de - sécurité élevé. Cela prendrai aussi + sécurité élevé. Cela prendrait aussi une demi-heure pour remplir les conditions de sécurité, ce qui pousserait les utilisateurs à éviter d'utiliser votre système. @@ -573,10 +574,10 @@ <simpara> Une phrase qui vaut la peine d'être retenue : un système est aussi fiable que son maillon le plus faible. Si toutes les - transactions sont exhaustivement noté (heure, lieu, type, etc...) + transactions sont exhaustivement notées (heure, lieu, type, etc...) mais que l'utilisateur n'est authentifié que par un cookie, la validité de votre système de surveillance est intimement - lié à la validité du cookie (et donc, + liée à la validité du cookie (et donc, sévèrement réduite). </simpara> <simpara> @@ -584,20 +585,20 @@ tester toutes les configurations, mais probablement les plus simples. Les données en entrées auxquelles vous pouvez vous attendre ne seront rien comparées aux données - incohérentes qu'un employé négligent, un - hacker disposant d'autant de temps qu'il veut, ou du chat de la + incohérentes d'un employé négligent, un + pirate disposant d'autant de temps qu'il veut, ou du chat de la maison marchant sur le clavier. Il est donc bon de regarder le - code logiquement, de voir d'où des données incohérentes + code logiquement, de chercher où des données incohérentes peuvent être introduites, modifiées, réduites ou amplifiées. </simpara> <simpara> L'Internet est rempli de personnes qui tentent de se faire une renommée - en piratant vos programmes, bloquant votre site, envoyant des contenus + en piratant vos programmes, en bloquant votre site, en envoyant des contenus inappropriés, qui rendent vos journées si "spéciales". Peut importe que vous ayez un grand portail ou un petit web, vous pouvez être la cible pour tout quidam avec une connexion. Vous êtes une - cible potentielle dès que vous êtes connecté vous même. + cible potentielle dès que vous êtes connecté vous-même. Certains programmes de piratage ne font pas dans la demi-mesure, et testent systématiquement des millions d'IP, à la recherche de victimes : ne soyez pas la prochaine. @@ -606,10 +607,10 @@ <sect1 id="security.current"> <title>Etre à jour</title> <simpara> - PHP, comme de nombreux systèmes de grandes tailles, est constamment + PHP, comme de nombreux systèmes de grande taille, est constamment testé et amélioré. Chaque nouvelle version rassemble des modifications majeures et mineures, aussi bien pour renforcer la - sécurité, réparer les problèmes de conceptions + sécurité, que pour réparer les problèmes de conceptions de configuration, et d'autres points qui peuvent affecter la sécurité globale et la stabilité de votre système. </simpara>