Dois-je m'inquiéter si mon site Web envoie des informations sur la pile?
J'ai un simple formulaire de connexion sur ma page Web et l'URL ressemble à ceci:
example.com/signup/signup.php?q=1
Si j'essaye quelque chose comme ça:
example.com/signup/signup.php?q=1&()
Je suis redirigé vers un vidage de pile qui ressemble à ceci:
exception 'DOMException' with message 'Invalid Character Error' in /<mydirectory>/a_xml.class.php:74
Stack trace:
#0 /<mydirectoy>/a_xml.class.php(74): DOMDocument->createElement('()')
...
#6 {main}
Est-ce un gros problème de sécurité? Y a-t-il des attaques qu'un utilisateur malveillant peut effectuer qui lui permettront de défigurer ou de voler ma base de données? Ou est-ce relativement bénin et je peux l'ignorer?
Dans les environnements de production (contrairement au développement), les traces de pile et les messages d'erreur doivent être enregistrés dans un fichier au lieu d'être vidés à l'écran. En effet, un attaquant peut apprendre des choses sur votre système qui pourraient compromettre votre système.
Des informations telles que le système d'exploitation, la version du serveur Web, PHP version et plus. Certaines traces de pile peuvent contenir des variables système/environnement qui ne doivent pas être rendues publiques!
L'utilisateur/visiteur devrait obtenir une page d'erreur HTTP agréable à regarder au lieu d'un message qui ne soit d'aucune utilité pour le visiteur.
Il y a deux aspects différents à cela:
- Le bug provoquant la trace de la pile est-il une vulnérabilité de sécurité?.
- Le cadre est-il configuré pour afficher les traces de pile aux étrangers.
Le message d'erreur Invalid Character Error ressemble beaucoup à une fuite oubliée, qui peut très souvent être exploitée d'une manière ou d'une autre. Vous devez donc vous préoccuper de la trace de la pile, car elle est le symptôme d'une éventuelle vulnérabilité de sécurité.
L'autre question est de savoir si vous devriez vous soucier de la présence de traces de pile aux étrangers. D'une part, cacher des informations sur les éléments internes d'un système peut être considéré comme une sécurité par l'obscurité. Dans la plupart des cas, je serais d'accord avec cela, mais pas en cas de traces de pile.
Les traces de pile n'apparaissent qu'en cas de problème, donc s'il y a jamais une trace de pile, il y a un risque important qu'il y ait un bogue, et s'il y a un bogue il y a un risque important qu'il puisse être exploité. Par conséquent, garder les traces de pile à l'écart des étrangers est une bonne idée. De plus, si la trace de la pile contient non seulement les noms des fonctions appelées mais également les valeurs des paramètres, elle peut facilement divulguer des clés, des mots de passe, des cookies ou d'autres types d'informations d'identification.
Pour les deux raisons ci-dessus, il est important de faire attention à l'endroit où vos traces de pile apparaissent.
Il est cependant important que les traces de pile soient disponibles pour ceux qui ont besoin de résoudre le problème. La journalisation des traces de pile est donc importante. Si les cas où les traces de pile sont des indications de failles de sécurité réelles, vous souhaitez les corriger dès que possible. Même si un message d'erreur non descriptif ne donnera pas beaucoup de travail à un attaquant, simplement en réalisant quels personnages fonctionnent et lesquels ne le font pas, ils peuvent éventuellement comprendre comment l'exploiter de toute façon.
Il y a deux problèmes ici, et l'OP pose des questions sur le problème le moins important.
Affichage de la trace
C'est la question que le PO pose. Il y a des débats concernant la quantité d'un problème montrant une trace est en général , et cet exemple particulier montre bien que l'affichage d'une trace peut être un problème de sécurité. La raison en est qu'elle nous informe (vous, moi et le pirate) de l'existence du deuxième problème.
Pas de filtrage des entrées utilisateur
Ceci est un vrai problème. Non seulement je sais (grâce à la trace) que votre application transmet des entrées utilisateur non filtrées et non validées aux fonctions natives PHP, je sais même que DOMDocument->createElement() est la fonction Je vais maintenant commencer à attaquer ce site et tous les sites que je peux identifier avec cette société pour d'autres problèmes de filtration, tels que l'injection SQL , XSS, CSRF, ad nauseum.
Notez que les traces de pile incluent des paramètres. S'il y a des appels de fonction qui transmettent des mots de passe comme arguments, ceux-ci se retrouveront dans des traces de pile.
C'est évidemment un désastre si un utilisateur peut lui renvoyer le mot de passe d'un autre. Moins évidemment, les mots de passe des utilisateurs se trouvent désormais dans des fichiers journaux; ce qui rendra vos utilisateurs très fous. À tout le moins, vous devez vous assurer que la journalisation des mots de passe ne se produit pas.
Dans votre exemple, les gens peuvent voir la structure de vos répertoires qu'ils pourraient utiliser pour d'éventuelles attaques. Vous seriez surpris de voir ce qu'un "pirate" peut faire avec très peu d'informations. Donc Oui en général c'est un gros problème en termes de sécurité. Comme le dit Alasjo, ce n'est pas non plus convivial et une page d'erreur est une bonne alternative.
Par exemple, dans certains cas, l'affichage d'erreurs aux utilisateurs peut conduire à: Traversée de chemin
La traversée de chemin est également connue sous le nom d'attaque ../ (barre oblique point), escalade de répertoire et retour en arrière.
Bien qu'il ait été fait allusion dans les commentaires ci-dessus, il pourrait être utile de noter qu'une raison
"Des informations telles que le système d'exploitation, la version du serveur Web, PHP et plus. Certaines traces de pile peuvent contenir des variables système/environnement qui ne devraient pas être rendues publiques!" (Voir le commentaire ci-dessus par @Alasjo et @Danny Beckett)
est mauvais, car le fait de connaître la pile logicielle utilisée pour créer votre application permet aux attaquants d'exploiter les failles de sécurité de ces composants (les problèmes de sécurité dans les logiciels courants sont des informations largement diffusées (voir https://cve.mitre.org/ )) en plus de tous les défauts/défauts de votre application mis en évidence dans les traces de la pile.
Par exemple, puisque je sais que votre site utilise PHP maintenant, je peux essayer toutes les failles de sécurité liées à PHP (dans le cas où vous n'avez pas corrigé votre = PHP installation pour corriger cette faille ... vous maintenez les niveaux de correctifs de votre pile logicielle à jour? :-)) même si votre application n'a révélé aucun de ses propres défauts dans la trace de la pile .