Rapport d'erreurs

En termes de s�curit�, il y a deux cons�quences au rapport d'erreur. D'un cot�, cela am�liore la s�curit�, mais d'un autre, cela la r�duit aussi.

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 pirate de lire de nombreuses informations sur le serveur, et de d�tecter des faiblesses du serveur. Par exemple, si un intrus a glan� des informations sur votre page, avec une premi�re utilisation de votre site, il peut essayer de remplacer les variables par ses propres valeurs :

Exemple #1 Attaque de site avec une page HTML personnalis�e

<form method="post" action="http://www.site.cible.com/?username=badfoo&password=badfoo">
 <input type="hidden" name="username" value="badfoo">
 <input type="hidden" name="password" value="badfoo">
</form>

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 quelle fonction a �chou�, quel fichier n'a pas �t� trouv�, quel script PHP a un bug, et quelle ligne est en faute. Toutes ces informations sont exploitables. Il est commun aux d�veloppeurs PHP d'utiliser les fonctions show_source(), highlight_string(), ou highlight_file() comme outils de d�boguage, mais sur un site en production, cela expose 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 les gestionnaires de d�bogage. Si l'intrus peut comprendre votre technique habituelle d'utilisation, il peut tenter une attaque frontale sur une page, en envoyant des cha�nes de d�bogage :

Exemple #2 Exploiter des variables classiques de d�bogage

<form method="post" action="http://www.site.cible.com/?errors=Y&showerrors=1"&debug=1">
 <input type="hidden" name="errors" value="Y">
 <input type="hidden" name="showerrors" value="1">
 <input type="hidden" name="debug" value="1">
</form>

Ind�pendamment de la gestion des erreurs, la possibilit� de tester la gestion des erreurs d'un syst�me conduit � un trou de s�curit�, et la diffusion de plus d'informations sur votre syst�me.

Si un pirate affiche une page html, et essaye de la tester (pour rechercher des faiblesses du syst�me), il peut d�terminer sur quel syst�me PHP a �t� compil�.

Une erreur de fonction indique si un syst�me supporte une base de donn�es sp�cifique, ou bien indique comment la page a �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 erron�es, par exemple, un pirate peut d�terminer l'ordre d'identification dans un script, � partir des lignes d'erreurs, et essayer de les exploiter ailleurs, dans le script.

Une erreur de fichier, ou une erreur g�n�rale PHP peut indiquer quelles sont les permissions du serveur web, ainsi que la structure et l'organisation des fichiers. Les gestionnaires d'erreurs utilisateurs peuvent aussi aggraver ce probl�me, en permettant l'exploitation facile d'informations pr�alablement cach�es.

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 deuxi�me est de 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. Suivant votre politique de s�curit�, vous pouvez utiliser un panachage savant des trois m�thodes.

Une m�thode pour gagner du temps est d'utiliser la fonction error_reporting(), pour vous aider � s�curiser le code, et d�tecter les utilisations dangereuses de variables. Vous testez votre code en b�ta test avec la valeur E_ALL, et vous pouvez rapidement rep�rer les variables qui ne sont pas prot�g�es. Une fois que le code est pr�t � �tre d�ploy�, vous devez soit d�sactiver compl�tement le rapport d'erreur en affectant 0 � la fonction error_reporting(), soit en d�sactivant l'affichage des erreurs en utilisant l'option de configuration display_errors du php.ini. Si vous choisissez la derni�re solution, vous devez �galement d�finir le chemin de votre fichier de log en utilisant la directive de configuration error_log, et en activant la directive log_errors.

Exemple #3 D�tecter des variables non prot�g�es avec E_ALL

<?php
if ($username) {
  
// Non initialis�e, ou v�rif�e avant utilisation
  
$good_login 1;
}
if (
$good_login == 1) {
  
// Si le test ci-dessus �choue, les valeurs n'ont pas �t� test�es
  
fpassthru ("/donn�es/tr�s/tr�s/sensibles/index.php");
}
?>