Discussion :

[WhoIsTiti]

bonjour,
je me suis aperçu dans un script php que j'utilise quand j'appelle un fichier celui ci renvoie un message bien trop bavard à mon goût:
sur IIS, il donne le chemin absolu du style :
C:\monrepetoire\repertoireduscript\fichier
sachant qu'au départ, C:\monrepertoire est mis en virtuel dans IIS.

sous apache linux, pas mieux, puisqu'il donne :
/home/stot/public_html/repertoireduscript/fichier.

quel danger cours les serveurs vulnérables à ce type de retour de message ?
ou bien est ce bénin ?

[Invité]

Bonjour,

En développement, on affiche le plus d'informations possibles pour faciliter le débogage.

Personnellement sur mes projets :

En développement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
display_errors = ON
display_startup_errors = ON
log_errors = ON
error_reporting = E_ALL

PHP est le plus bavard possible, il affiche les erreurs, les enregistres dans le fichier .log et affiche tous les erreurs et avertissements.

En production :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
display_errors = OFF
display_startup_errors = OFF
log_errors = ON
error_reporting = E_ALL

PHP n'affiche pas les erreurs, il les log uniquement.

Le must étant de réaliser en plus, un système de gestion d'erreurs à côté.

Documentation sur le manuel PHP :
display-errors
display-startup-errors
log-errors
display-errors
error-reporting

[WhoIsTiti]

merci Karzoff, mais ça ne répond pas du tout à ma question.
(à titre personnel, je suis en STRICT pour développer)

[RunCodePhp]

merci Karzoff, mais ça ne répond pas du tout à ma question.

Et bien si, totalement même.

D'ailleurs, cette info y est à plusieurs reprise dans le php.ini, exemple :

; display_errors
; Default Value: On
; Development Value: On
; Production Value: Off

Par exemple, tu mets le display_errors à On quand tu développe chez toi, ce qui te permettras de débugger ton code.
Sur le Net, tu mets cette config à Off, les messages d'erreurs ne seront pas affichés, donc pas de chemin, plus de problème.

Après, selon son imagination ou/et connaissances, on peu pousser plus loin la gestion des erreurs.

[WhoIsTiti]

décidément, non, vous ne répondez pas clairement à la question :
quels dangers pour les serveurs (sous gnu/linux ou ISS) d'avoir un display error encore sur on ? (ça ne me concerne pas puisque le mien est sur off)
Venant du monde dotnet, la gestion des erreurs (bloc try/catch) est ,en phase de dev, essentielle, quelque soit le type d'appli.
c'est pas des conseils techniques que je cherche, mais plus des avis d'un point de vue sécurité.

edit: en fait, j'aurais pas dû poser la question sur cette section du forum, mais plutôt dans celles qui traitent de sécurité sur les serveurs web.

[RunCodePhp]

décidément, non, vous ne répondez pas clairement à la question :
quels dangers pour les serveurs (sous gnu/linux ou ISS) d'avoir un display error encore sur on ?

Désolé, mais je ne vois pas d'autres réponses à te donner que celles déjà données.

Le risque me parait évident, et tu as toi même fait la remarque.
Afficher les chemins complets en cas d'erreurs sera une indication du comment est structurer le serveur, donc facilitera la tâche d'un pirate à pirater.
A l'inverse, n'afficher aucune indication relative au serveur obligera un pirate à les rechercher, ou faire autrement.

Sinon, je ne vois pas qu'est ce tu sous entendrait d'autres par danger, sinon tu explique mal ton problème.
A savoir que depuis Php5, on peu gérer les erreurs avec des try/catch.

[Invité]

Désolé de ne pas avoir cerné ta question. Quand tu disais :

je me suis aperçu dans un script php que j'utilise quand j'appelle un fichier celui ci renvoie un message bien trop bavard à mon goût:

Je comprenais que c'était une erreur qui était affichée lors de l'utilisation de ton application PHP.

Sécurité par l'obscurité (wikipedia)

Le risque principal comme l'a dit RunCodePhp, est que cela donne des informations sur la structure du serveur web : cela facilite le fingerprinting (récupération d'informations sur la structure d'un Système d'Information). En un coup d'œil, on peut voir sous quel type d'OS tourne le serveur web, éventuellement trouver l'emplacement sur le serveur de chemins sensibles (répertoire include, répertoire admin, chemin d'apache ou de mysql)

Concrètement, le risque, c'est que cela facilite l'exploitation de failles de type faille include