archived-doc-fr/security/errors.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<!-- EN-Revision: ae725a44023db78b9f6e9d2a0baac8c8dc337d38 Maintainer: lacatoire Status: ready -->
<!-- Reviewed: yes Maintainer: pmartin -->

<chapter xml:id="security.errors" xmlns="http://docbook.org/ns/docbook">
 <title>Rapport d'erreurs</title>
 <para>
  En termes de sécurité, il y a deux conséquences au rapport d'erreur.
  D'un côté, cela améliore la sécurité, mais d'un autre, cela la réduit aussi.
 </para>
 <para>
  Une tactique d'attaque standard consiste à faire faire des erreurs
  au système, et à analyser les types des erreurs qui sont retournées,
  ainsi que leur contexte. Cela permet à l'attaquant d'obtenir des
  informations à propos du serveur, en vue de détecter de possibles faiblesses.
  Par exemple, si un intrus a glané des informations sur une page dépendant
  de la soumission préalable d'un formulaire, il peut essayer d'écraser les
  variables par ses propres valeurs :
  <example>
   <title>Attaque de variables avec une page HTML personnalisée</title>
   <programlisting role="html">
<![CDATA[
<form method="post" action="attacktarget?username=badfoo&amp;password=badfoo">
<input type="hidden" name="username" value="badfoo" />
<input type="hidden" name="password" value="badfoo" />
</form>
]]>
   </programlisting>
  </example>
 </para>
 <para>
  Les erreurs PHP qui sont normalement retournées peuvent être
  très pratiques pour un développeur qui essaie de déboguer un
  script, car elles donnent de précieux renseignements tels que
  la fonction qui a échoué, depuis quel fichier PHP, et même le numéro
  de la ligne à laquelle l'erreur s'est produite. Toutes ces informations sont exploitables.
  Il n'est pas rare que les développeurs PHP utilisent
  les fonctions <function>show_source</function>,
  <function>highlight_string</function>, ou
  <function>highlight_file</function> comme outils de débogage, mais sur un
  site en production, cela peut exposer des variables cachées, des syntaxes non
  vérifiées, ou d'autres informations critiques. Il est particulièrement
  dangereux d'exécuter du code de sources connues avec des gestionnaires de
  débogage inclus, ou de travailler avec des techniques de débogage répandues.
  Si l'attaquant peut déterminer quelle technique générale est utilisée, il peut
  tenter une attaque frontale sur une page, en envoyant des chaînes de débogage connues :
  <example>
   <title>Exploiter des variables classiques de débogage</title>
   <programlisting role="html">
<![CDATA[
<form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;debug=1">
<input type="hidden" name="errors" value="Y" />
<input type="hidden" name="showerrors" value="1" />
<input type="hidden" name="debug" value="1" />
</form>
]]>
   </programlisting>
  </example>
 </para>
 <para>
  Indépendamment de la méthode de gestion des erreurs, la possibilité de tester
  un système pour identifier des erreurs revient à fournir à un attaquant
  plus d'informations sur le système.
 </para>
 <para>
  Par exemple, le style même d'une erreur PHP standard indique qu'un système fait
  tourner PHP.
  Si un attaquant affiche une page <literal>.html</literal>, et essaye de la tester (pour rechercher des
  faiblesses connues du système), en lui envoyant des données invalides, il peut déterminer
  qu'elle a été construite via un script PHP.
 </para>
 <para>
  Une erreur de fonction peut indiquer si un système supporte une base de
  données spécifique, ou bien donner des indices quant à la façon dont une page a
  été conçue ou développé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
  erronées, par exemple, un pirate peut déterminer l'ordre
  d'identification dans un script (à partir des numéros de lignes d'erreurs),
  ou sonder à la recherche de failles qui pourraient être exploitées à
  différents endroits du script.
 </para>
 <para>
  Une erreur de fichier, ou une erreur générale de PHP, peut indiquer
  quelles sont les permissions du serveur web, ainsi que la structure
  et l'organisation des fichiers. Le code de gestion d'erreurs écrit par le
  développeur peut aussi aggraver ce problème, en permettant l'exploitation facile
  d'informations préalablement "cachées".
 </para>
 <para>
  Il y a trois solutions majeures à ces problèmes : la première
  est de scruter toutes les fonctions, et d'essayer de traiter toutes les
  erreurs. La seconde est de totalement désactiver le rapport d'erreur, dès
  que le script est en production. La troisième est d'utiliser les
  fonctions de gestion des erreurs de PHP pour créer des gestionnaires d'erreurs personnalisés.
  En fonction de la politique de sécurité en place, il se peut que
  ces solutions soient toutes les trois applicables.
 </para>
 <para>
  Une méthode pour gagner du temps est d'utiliser la fonction
  <function>error_reporting</function>, pour aider à
  sécuriser le code et détecter certaines utilisations dangereuses de variables.
  En testant le code avant le déploiement avec <constant>E_ALL</constant>,
  il est possible de rapidement repérer les variables qui ne sont pas protégées.
  Une fois que le code est prêt à être déployé, il est recommandé soit de désactiver complètement
  le rapport d'erreur en passant 0 à la fonction <function>error_reporting</function>,
  soit de désactiver l'affichage des erreurs en utilisant l'option de configuration
  <literal>display_errors</literal> de &php.ini;. En choisissant la
  seconde solution, il est également recommandé de définir le chemin vers le fichier
  de log en utilisant la directive de configuration <literal>error_log</literal>,
  et d'activer la directive <literal>log_errors</literal>.
  <example>
   <title>Détecter des variables non protégées avec E_ALL</title>
   <programlisting role="php">
<![CDATA[
<?php
if ($username) {
  // Non initialisée ou vérifiée avant utilisation
  $good_login = 1;
}
if ($good_login == 1) {
  // Si le test ci-dessus échoue, les valeurs n'ont pas été testées
  readfile ("/données/très/très/sensibles/index.html");
}
?>
]]>
   </programlisting>
  </example>
 </para>
</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
-->