<?php
include_once $_SERVER['DOCUMENT_ROOT'] . '/include/shared-manual.inc';
$TOC = array();
$TOC_DEPRECATED = array();
$PARENTS = array();
include_once dirname(__FILE__) ."/toc/security.inc";
$setup = array (
  'home' => 
  array (
    0 => 'index.php',
    1 => 'PHP Manual',
  ),
  'head' => 
  array (
    0 => 'UTF-8',
    1 => 'fr',
  ),
  'this' => 
  array (
    0 => 'security.variables.php',
    1 => 'Donn&eacute;es transmises par les internautes',
    2 => 'Donn&eacute;es transmises par les internautes',
  ),
  'up' => 
  array (
    0 => 'security.php',
    1 => 'S&eacute;curit&eacute;',
  ),
  'prev' => 
  array (
    0 => 'security.errors.php',
    1 => 'Rapport d\'erreurs',
  ),
  'next' => 
  array (
    0 => 'security.hiding.php',
    1 => 'Masquer PHP',
  ),
  'alternatives' => 
  array (
  ),
  'source' => 
  array (
    'lang' => 'fr',
    'path' => 'security/variables.xml',
  ),
  'history' => 
  array (
  ),
);
$setup["toc"] = $TOC;
$setup["toc_deprecated"] = $TOC_DEPRECATED;
$setup["parents"] = $PARENTS;
manual_setup($setup);

contributors($setup);

?>
<div id="security.variables" class="chapter">
 <h1 class="title">Données transmises par les internautes</h1>

 <p class="para">
  La plus grande faiblesse de nombreux programmes <abbr title="PHP: Hypertext Preprocessor">PHP</abbr> ne vient pas
  du langage en lui-même, mais de son utilisation en omettant les
  caractéristiques de sécurité. Pour cette raison,
  il est recommandé de toujours prendre le temps de réfléchir aux implications
  d&#039;une portion de code donnée, pour mesurer les éventuels dommages
  qui pourraient être causés si une variable inattendue lui était passée.
  <div class="example" id="example-1">
   <p><strong>Exemple #1 Utilisation dangereuse de variables</strong></p>
   <div class="example-contents">
<div class="phpcode"><code><span style="color: #000000"><span style="color: #0000BB">&lt;?php<br /></span><span style="color: #FF8000">// efface un fichier à la racine d'un utilisateur... ou peut-être<br />// de quelqu'un d'autre ?<br /></span><span style="color: #0000BB">unlink</span><span style="color: #007700">(</span><span style="color: #0000BB">$evil_var</span><span style="color: #007700">);<br /></span><span style="color: #FF8000">// Enregistre l'accès dans un log... ou peut-être une entrée dans /etc/passwd ?<br /></span><span style="color: #0000BB">fwrite</span><span style="color: #007700">(</span><span style="color: #0000BB">$fp</span><span style="color: #007700">, </span><span style="color: #0000BB">$evil_var</span><span style="color: #007700">);<br /></span><span style="color: #FF8000">// Exécute une commande triviale... ou rm -rf * ?<br /></span><span style="color: #0000BB">system</span><span style="color: #007700">(</span><span style="color: #0000BB">$evil_var</span><span style="color: #007700">);<br /></span><span style="color: #0000BB">exec</span><span style="color: #007700">(</span><span style="color: #0000BB">$evil_var</span><span style="color: #007700">);<br /></span><span style="color: #0000BB">?&gt;</span></span></code></div>
   </div>

  </div>
 </p>
 <p class="para">
  Il est vivement recommandé d&#039;examiner minutieusement le code
  pour s&#039;assurer qu&#039;il n&#039;y a pas de variable envoyée par le
  client web qui ne soit pas suffisamment vérifié avant utilisation,
  en se posant les questions suivantes :
  <ul class="itemizedlist">
   <li class="listitem">
    <span class="simpara">
     Est-ce que ce script n&#039;affectera que les fichiers prévus ?
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     Est-il possible que des valeurs incohérentes ou inattendues soient exploitées ici ?
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     Est-ce que ce script peut être utilisé dans un but différent de celui attendu ?
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     Est-ce que ce script peut être utilisé malicieusement,
     en conjonction avec d&#039;autres ?
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     Est-ce que toutes les actions seront correctement historisées ?
    </span>
   </li>
  </ul>
 </p>
 <p class="para">
  En répondant de manière adéquate à ces questions
  lors de l&#039;écriture des scripts (plutôt qu&#039;après), cela
  évitera une réécriture inopportune lorsqu&#039;il faudra améliorer leur
  sécurité. En commençant les projets avec ces recommandations
  en tête, la sécurité du système ne sera pas garantie,
  mais elle s&#039;en trouvera améliorée.
 </p>
 <p class="para">
  Il est recommandé d&#039;améliorer la sécurité en désactivant les paramètres de commodité qui masquent
  l&#039;origine, la validité ou l&#039;intégrité des données en entrée. La création
  implicite de variables et l&#039;absence de vérification des entrées peuvent
  entraîner des vulnérabilités telles que des attaques par injection et des
  manipulations de données.
 </p>
 <p class="para">
  Des fonctionnalités comme <code class="literal">register_globals</code> et
  <code class="literal">magic_quotes</code> (toutes deux supprimées à partir de PHP 5.4.0)
  contribuaient autrefois à ces risques en créant automatiquement des variables
  à partir des entrées utilisateur et en échappant les données de manière incohérente.
  Bien qu&#039;elles ne soient plus présentes dans PHP, des risques similaires
  persistent si la gestion des entrées est mal maîtrisée.
 </p>
 <p class="para">
  Activer <a href="function.error-reporting.php" class="link">error_reporting(E_ALL)</a>
  pour aider à détecter les variables non initialisées et à valider les entrées.
  Utiliser les types stricts
  (<a href="language.types.declarations.php#language.types.declarations.strict" class="link">declare(strict_types=1)</a>,
   introduit à partir de PHP 7) pour imposer la sécurité des types, éviter
  les conversions involontaires et améliorer la sécurité globale.
 </p>
</div>
<?php manual_footer($setup); ?>