Rapport d'erreurs

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.

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 :

<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>

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 show_source(), highlight_string(), ou highlight_file() 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 :

<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>

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.

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 .html, 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.

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.

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".

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.

Une méthode pour gagner du temps est d'utiliser la fonction error_reporting(), pour aider à sécuriser le code et détecter certaines utilisations dangereuses de variables. En testant le code avant le déploiement avec E_ALL, 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 error_reporting(), soit de désactiver l'affichage des erreurs en utilisant l'option de configuration display_errors 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 error_log, et d'activer la directive log_errors.